IPv4 vs. IPv6: do you actually need extra IPv4 addresses

Why IPv4 addresses are a scarce resource

IPv4 uses a 32-bit address space, which sounds like a lot until you consider how many devices and services now need an address. That space ran out years ago in the sense that matters: the regional registries that used to hand out fresh IPv4 blocks for free are depleted, and the only way to get IPv4 addresses now is to acquire them from someone who already holds them, on an open market. That scarcity is a general industry fact, not specific to any one provider, and it's the reason additional IPv4 addresses carry an ongoing cost wherever you host. What comes with a Worldstream server, and how you add more, is covered in IPv4 and IPv6 addresses on your server. For what any of it costs, check the current pricing on worldstream.com or open a ticket in Portal: neither article states a figure.

IPv6 doesn't have that scarcity problem. Its address space is vastly larger, allocations are generous, and there's no equivalent open market driving up the cost of getting more of it.

When you genuinely need more than one IPv4 address

Needing extra IPv4 addresses is usually driven by a specific technical constraint, not a general preference. The common ones:

• Multiple TLS certificates on systems that don't support SNI. Server Name Indication (SNI) lets a single IP serve multiple HTTPS certificates by having the client announce which hostname it wants during the TLS handshake. Modern browsers and servers support it, but some legacy clients and older embedded or appliance software don't, and for those, each certificate still needs its own IP.
• Separate mail servers. Email deliverability is tied heavily to the reputation of the sending IP address and its reverse DNS record. Running more than one mail server, or wanting to isolate a bulk-sending stream from a transactional one, generally means giving each its own IP so one server's reputation problems don't affect the other.
• Licensing tied to a specific IP address. Some commercial software licences are bound to an IP address rather than a hostname or hardware ID, which forces a dedicated, stable IPv4 address for that system.
• Multi-tenant hosting where each customer needs their own address. If you're reselling hosting, or running infrastructure where each tenant needs to be reachable on a distinct IP (for SSL, for firewall rules, for isolation), that's a direct one-IP-per-tenant requirement.

When IPv6 alone is enough

For a growing share of workloads, IPv6 alone is genuinely sufficient:

• Modern web services sitting behind a reverse proxy or load balancer, where the proxy is what's internet-facing and backend systems don't need public addresses of their own at all.
• API backends, especially ones consumed by other services and modern clients rather than directly by end users' browsers.
• Internal infrastructure that doesn't need to be publicly reachable on IPv4 in the first place.
• Anything where you control both ends, or where the clients and dependencies involved support IPv6, which describes most current operating systems, browsers, and cloud services now.

The honest caveat is reach: if you need to guarantee reachability from every possible client on the internet, including older networks or devices that still lack IPv6 connectivity, IPv4 reachability still matters. That's shrinking over time, but it hasn't disappeared.

Dual-stack: the common default, not a decision you're forced into

In practice, most real deployments don't pick IPv4 or IPv6, they run dual-stack: a server holds both an IPv4 and an IPv6 address simultaneously, and clients connect over whichever protocol they support, with IPv6 typically preferred where available. Dual-stack sidesteps the either/or framing entirely. It means you're not trying to guess in advance whether every future client will have IPv6, while still not needing extra IPv4 addresses just to have basic reachability, one IPv4 address alongside IPv6 covers that. Extra IPv4 addresses become a question you answer separately, driven by the specific needs above, rather than a default you reach for.