IPv4 Exhaustion: Address Planning for Hosting

IPv4 exhaustion affects address availability and infrastructure planning, but it does not mean existing addresses stop working or prices must always rise. This guide separates allocation policy from market pricing, then examines ways to reduce unnecessary address assignments while preserving the connections your users and applications need.

When comparing hosting, VPS, dedicated server or colocation options, include public IP requirements alongside CPU, memory and storage. We will cover inventory, email, shared web ingress and IPv6 migration, ending with questions to resolve in a provider quote. The goal is a measurable address plan, with costs and responsibilities made explicit.

IPv4 Exhaustion: What Ran Out and What Still Works

A finite address space

IPv4 has a 32-bit address space: approximately 4.3 billion possible addresses, or 2³². That is not the number of usable public server addresses; private and special-purpose ranges are included. Nor does each device require a separate public IPv4: private networks and shared gateways allow multiple workloads to use common public endpoints.

IANA’s free pool was exhausted on 3 February 2011, when its final five /8 blocks were distributed to the Regional Internet Registries. Regional pools did not all run out on that date. RIPE NCC made its final /22 allocation from its remaining pool on 25 November 2019. These milestones concern new allocations, not the continued operation of existing addresses.

Transfers, recovered space and remaining reserves are governed by the relevant registry’s policies. They reuse existing address space rather than enlarge it. Avoid treating one region’s rules as a universal allocation policy, or confusing a provider’s extra-IP assignment with a registry allocation to a network operator.

Waiting lists and transfers have eligibility conditions

Two routes to address space require different checks:

• RIPE NCC waiting list: under its published conditions, an eligible Local Internet Registry (LIR) that has never received an IPv4 allocation from RIPE NCC can request one /24, or 256 addresses. Allocation depends on recovered space and the queue; there is no promised delivery date. A hosting customer is not automatically an eligible LIR.
• Transfer or lease: establish who can authorize use, which registry rules apply, and whether the intended provider will route the space. Payment to a broker alone does not establish transfer approval or network compatibility.

ARIN IP transfer policies and operational checks explains the registry side of a transfer. For an externally acquired block, confirm BYOIP/address-import support, accepted prefix size, service and region before committing. Provider-supplied extra IPs and externally sourced blocks are different procurement choices.

What Affects IPv4 Prices?

Finite space does not mean prices always rise

Scarcity can create cost pressure, but changing inventory and demand can also bring prices down. ARIN’s assessment published on 22 January 2026 describes falling observed transfer prices during 2025. That dated observation is neither a current hosting tariff nor a quote for every block.

• Available inventory: unused space can enter the market or be recovered, even though the protocol’s address space is fixed.
• Actual service requirements: fixed source allowlists, some protocols and legacy clients may need distinct addresses. Modern HTTPS generally supports sharing through SNI.
• Migration constraints: IPv6 readiness varies across applications and dependencies; adding IPv6 does not automatically eliminate retained IPv4 assignments.

Our earlier discussion of IPv4 address prices provides further context. Treat historical price descriptions as dated material. Compare current offers with the same block size, term, currency, transfer conditions and included services; do not assume a previous high or low persists.

From market acquisition to a hosting invoice

Different network designs create different address requirements. Examples include:

• Content and SaaS services: shared web ingress, distinct outbound allowlist addresses or sending-IP separation where justified.
• Access networks: public endpoints shared through NAT, subject to connection capacity and attribution requirements.
• Enterprise integrations: existing VPNs, partner endpoints and devices whose address-family support must be verified before migration.

An address-transfer price is not the same as a monthly extra-IP charge. A provider quote may also include routing, management, support and contractual conditions. Separate acquisition or setup fees from recurring allocation charges, and record when charges stop after an address is returned.

Address history is an operational consideration

Before using an address, examine more than a single “clean” label:

• Check relevant blocklists and the available history of outbound spam or other abuse.
• Review routing authority, registration and geolocation data relevant to your service.
• Determine who can manage PTR records and handle complaints or correction requests. A successful check today is not a future delivery guarantee.

The email reputation and recovery guide covers investigation and gradual sending. If a service is compromised or sends unwanted mail, fix that cause first. Moving it to a new IP does not remediate the underlying problem or guarantee that recipients will accept its messages.

For email, choose shared or dedicated sending according to volume, regularity and isolation needs. A well-managed shared service can suit low-volume senders. Include monitoring and remediation effort in the budget; paying for a dedicated address does not buy inbox placement.

How Address Requirements Affect Hosting and SaaS

Document assignment and return rules

Before requesting more space, establish a reason for each assignment:

• Use separate addresses where routing, source allowlists, protocol behavior or justified sending separation requires them.
• Use SNI and name-based virtual hosting where clients support them; each hostname still needs correct certificate coverage and server mapping.
• Review unused assignments, but verify DNS, active connections and external dependencies before returning or reallocating an address.

An inventory should include the service owner, usage reason, DNS/PTR records, partner allowlists, contract and charge. Mark possible consolidation candidates separately from addresses that can already be returned. This avoids treating an apparently idle address as proof that no dependency remains.

Identify the designs with a high address cost

Some requirements can increase public address demand. Record the specific reason rather than assigning by habit:

• Multi-tenant SaaS: a customer may need a fixed source IP for an allowlist; a branded hostname alone does not require a dedicated IP.
• Outbound email: separate streams may justify different sending addresses, but there is no blanket need for multiple /24s. Volume and reputation management govern the decision.
• Legacy software: confirm whether the protocol or client actually prevents virtual hosting or SNI.
• VPN or remote access: verify any contractual promise of a dedicated endpoint and the peer’s supported address families.

For capacity planning, model IP cost per tenant or node alongside shared ingress, NAT and email-service costs. State which expenses are fixed and which grow with usage. A single shared gateway may reduce address assignments while adding capacity or availability requirements of its own.

Keep reachability, abuse and routing risks separate

The following risks need different controls:

• Abuse and blocklists: stop the offending activity and verify remediation before deciding whether an address change is needed. Being a DDoS target is not itself evidence of poor sending reputation.
• Multihoming and BGP: confirm the announcing ASN, accepted prefix lengths, authorization and provider support. A larger block alone does not provide resilient routing.
• Partner dependencies: list endpoints and access controls that remain IPv4-only, together with their change process. Do not infer a legal requirement merely because an integration uses IPv4.

An application can support IPv6 while a payment endpoint, VPN peer or partner allowlist still depends on IPv4. Test the full connection path before retiring the required IPv4 route. Track an owner and a migration condition for each exception so temporary dependencies do not disappear from the plan.

Practical Ways to Consolidate IPv4 Use

1. Audit and retire unused assignments

Start with changes that have clear ownership and measurable outcomes:

• Map public IPv4 to servers, load balancers, egress gateways, services and billing records.
• Review per-domain assignments retained only because of an old TLS assumption; test SNI and client compatibility before consolidating.
• Identify retired staging environments, VMs and applications, then verify that DNS, monitoring and external allowlists no longer depend on their addresses.

Treat reclamation as a change, with an acceptance test and rollback plan. Lower relevant DNS TTLs before a move and allow the previous TTL interval; changing the authoritative TTL does not rewrite cached answers. Observe real traffic and dependencies before release, then confirm the billing effect.

2. Share HTTPS ingress with SNI

SNI lets a TLS client indicate the hostname it is trying to reach, allowing a server to select the appropriate certificate on a shared address. Modern web clients commonly support it. Confirm certificate coverage, virtual-host mapping and any legacy-client exception before removing a dedicated IP.

A shared proxy can serve web and API hostnames, but it must enforce the correct application routing and access rules. An admin hostname still needs authentication and restricted access. In multi-tenant systems, hostname-to-tenant mapping does not replace per-request tenant authorization or domain ownership verification.

3. Use ports without mistaking them for isolation

Different port numbers can distinguish services on one address, but separate ports do not provide security isolation. For example, a VPS might expose:

• The main HTTPS application on port 443.
• An administrative endpoint on port 8443 or 9443, restricted by a VPN or suitable access policy and authentication.
• Internal microservices on different private listeners, reached through an authorized proxy rather than exposed directly to everyone.

Private addressing and NAT also need explicit firewall policy. For shared outbound NAT, size concurrent connections and ports, review timeouts, and record enough timestamp, protocol and address/port mapping data to attribute activity. Include gateway charges and failure impact in the comparison.

4. Plan justified larger address requirements

If distinct addresses remain necessary, establish these conditions before acquisition:

• Routing and authority: confirm provider acceptance, prefix size and the announcing ASN. Required authorization, routing records and any ROA must match the intended origin and prefix length; origin validation does not validate the complete AS path.
• Email operations: verify SPF, DKIM, DMARC and rDNS, sending history and measured recipient response. SRS and ARC for forwarding address different forwarding issues; they do not replace source remediation or promise delivery.
• Internal services: retain private RFC1918 space with appropriate gateways where public IPv4 is unnecessary; account for logging, capacity and access controls.

For dedicated or colocation environments, document who owns every routing, PTR and incident task. Include block-return or transfer arrangements at contract end. Contiguous space may simplify route planning, but actual reachability and redundancy depend on the agreed network design.

Plan IPv6 Adoption Around Real Dependencies

Dual-stack prepares a transition; it does not release IPv4

IPv6 adoption does not establish a predictable IPv4 price trajectory. Legacy dependencies can sustain demand, while consolidation can release addresses. A migration decision is more useful when based on required connectivity and total cost than on a forecast that IPv4 must stay expensive or become cheap.

Dual-stack retains IPv4 while adding IPv6. More traffic over IPv6 does not by itself reduce the number of billed IPv4 assignments. Savings arise only when assignments can be removed or avoided without breaking required access, and after accounting for any new gateway, proxy or operational costs.

Planning IPv6 adoption and the dual-stack AAAA testing guide describe related implementation steps. Choose a small pilot, define acceptance criteria and keep a rollback route. Evaluate reachability and operating effort as well as traffic share.

Start with a suitable web or API endpoint

A manageable pilot is one whose clients, dependencies and support owners are known. Before publishing AAAA records:

• Confirm IPv6 routing and the allocated address/prefix for the exact service and location.
• Configure and test the web or proxy listener, certificate and firewall/WAF rules over IPv6.
• Test from external networks; if using a CDN or proxy, test client-to-edge and edge-to-origin paths separately.
• Publish AAAA only after the path works, then monitor both address families and retain the required IPv4 route.

Clients may attempt IPv6 and IPv4 according to their connection-selection behavior. A working IPv4 fallback is not a substitute for fixing broken IPv6. Compare connection failures and latency by family; do not assume that adding IPv6 is always faster or automatically reduces the address bill.

Test email separately

Sending over IPv6 needs its own compatibility and reputation checks:

• Verify PTR and forward DNS for the sending address: the PTR hostname should resolve back to the sender using A for IPv4 or AAAA for IPv6.
• Confirm SPF authorization where applicable, DKIM signatures and DMARC alignment. Adding IPv6 does not replace these controls.
• Use gradual, consistent sending to permitted recipients; monitor deferrals, bounces, complaints and recipient-specific rules before increasing volume.

Email deliverability over IPv6 covers this workflow in more detail. Keep the required IPv4 route while running limited trials. A dedicated IP and a warm-up plan do not guarantee delivery, and adding a second address family does not remove the need for a rollback plan.

Separate IPv6-only backends from IPv4 ingress

In a common NAT64/DNS64 arrangement, an IPv6 client uses a synthesized AAAA response and a translator to initiate a connection to an IPv4 destination. This does not automatically make an IPv6-only website reachable by IPv4 visitors. For that ingress, design a separate path such as a proxy or CDN that accepts IPv4 and connects to the IPv6 backend. Suitable pilot candidates include:

• Internal microservices whose dependencies support IPv6.
• New applications with an explicitly tested shared ingress and egress design.
• Lab or staging jobs where connection failures can be investigated before production use.

The IPv6-only VPS architecture guide expands on the options. Test literal IPv4 dependencies, application support and the chosen DNS64/DNSSEC validation arrangement; DNS64 alone does not solve every compatibility issue. Shared translators and proxies still consume capacity and may need IPv4 addresses. If a backend already used private IPv4, replacing it with IPv6 alone does not free a public assignment.

Resolve Provider Scope Before Committing

Confirm the exact product, location and terms

When asking DCHost or another provider for a quote, describe your required connectivity and verify the offered scope. This article is not a commitment that every product includes IPv6, external-address routing or on-demand IPv4 availability. Request written details for the service you intend to use:

• Included IPv4 assignments, extra-IP price, eligibility conditions, available quantity and provisioning time.
• IPv6 allocation and routing, PTR controls, firewall/load-balancer compatibility and support responsibility for the selected location.
• External-block/BYOIP acceptance, renewal and return terms, DDoS coverage and abuse-handling responsibilities where relevant.

Compare setup and recurring charges over the same term. Record what happens if an address changes, a service moves or the contract ends. The plan is ready only when required capabilities, ownership and timing are confirmed, rather than inferred from a general service description.

Turn the inventory into a deployment plan

Use three groups of questions to choose and sequence work:

• Launch and growth: which public addresses are required now, which are spare, and what measured growth threshold justifies another assignment?
• Compatibility: which services can share ingress or add IPv6, and which client, partner or protocol constraints remain?
• Acceptance and rollback: who tests each address family, monitors failures and billing, and authorizes release of the old assignment after dependencies have moved?

IPv6 adoption and its implications for a site provides additional context. Keep the project decision grounded in its own access requirements. A higher IPv6 traffic share, a smaller public address inventory and a lower total bill are three separate outcomes to measure.

Choose One Measurable Change

IPv4 exhaustion is an allocation constraint, not a reason to move a stable project in haste. Start with a verified inventory and distinguish required addresses from inherited assumptions. Use current supplier terms and dated market evidence without turning either into a guaranteed price forecast.

A first change might retire an unused staging assignment, consolidate suitable HTTPS sites, or add IPv6 to one endpoint. Each has a different success measure. Preserve required access, test the rollback route and compare actual costs and failures before expanding the change.

For a DCHost service quote, provide the address inventory, protocols, location, expected growth and target migration date. Once the service scope is confirmed, attach the test plan and owner for each dependency. Review the result when a contract renews or the workload changes, so address planning remains tied to real requirements.