IPv4 vs IPv6 on VPS

IPv4 was designed for a smaller internet than we have. Its 32-bit address space allows approximately 4.3 billion unique addresses, which seemed sufficient in the 1980s and became insufficient decades before the problem was fully solved. IPv6 uses 128-bit addresses, providing 340 undecillion addresses — enough to assign billions of addresses to every square centimeter of the Earth's surface. The scarcity problem is solved in IPv6. The transition problem is not.

Transitioning from IPv4 to IPv6 requires every device, router, ISP, and server to support IPv6 before IPv4 can be retired. That transition has been underway for decades and is still incomplete. Mobile networks and modern consumer ISPs have largely completed IPv6 adoption. Enterprise networks, some ISPs, and significant portions of the internet's infrastructure still run IPv4-only. A server that is reachable only via IPv6 is unreachable to users on IPv4-only networks.

Most VPS plans include one IPv4 address and a range of IPv6 addresses. The IPv4 address is what most users will reach the server on — it's the address that goes in DNS records for public-facing services, what monitoring services probe, and what legacy infrastructure expects. The IPv6 range is available for services that can use it, and for future-proofing as IPv6 adoption continues.

For internal services — backend APIs, databases, inter-server communication — IPv6 works without compatibility concerns if all communicating parties support it. A cluster of VPS instances communicating with each other can use IPv6 exclusively for internal traffic, reserving IPv4 for public-facing endpoints. This reduces dependence on scarce IPv4 addresses without creating compatibility issues.

DNS configuration matters for dual-stack deployments. A domain with both A records (IPv4) and AAAA records (IPv6) will be reached via IPv6 by clients that support it and via IPv4 by clients that don't. Modern operating systems prefer IPv6 when available. This means a dual-stack server serves most modern clients over IPv6 automatically, without any application changes required.

Some providers offer IPv6-only plans at significantly lower prices, relying on NAT64 or proxy mechanisms to provide IPv4 reachability. These work for most use cases but fail for workloads that need a dedicated public IPv4 address: sending email (SMTP servers are frequently blocked when sending from shared or NATted IPs), running services that query IPv4-only external APIs, or operating services where clients connect to specific IPs rather than domain names.

Third-party integrations are the quiet IPv6 failure. A payment processor, an SMS gateway, a webhook endpoint, an IP-based API client — these may not support IPv6, or may not have updated their documentation to reflect it. Discovering this after migrating to an IPv6-only server during a production issue is expensive. Checking integration compatibility before the migration is not.

IPv4 address costs are moving in one direction. Providers absorbing the secondary market cost of IPv4 addresses today will increasingly pass that cost to users as their own IPv4 allocation ages and requires replenishment. The $0 included IPv4 address of 2020 is becoming a $3-5/month line item at forward-looking providers. This isn't a reason to avoid IPv4 now — it's a reason to understand that the cost structure is shifting.

IPv6-only infrastructure is viable today for a specific set of workloads: internal services, development environments, applications that control all clients, and services with no IPv4-only integration dependencies. What you gain is lower cost and freedom from address scarcity. What you give up is guaranteed reachability from the legacy internet — which still represents a meaningful fraction of global internet traffic and essentially all enterprise network infrastructure.