VPSTabEvidence-first VPS decisions
Search2026.10.25-v7
Menu
Find a VPSProvidersPlansReviewsCompareUse casesGuidesMethodology
English
English简体中文日本語한국어DeutschFrançaisРусский
Guides

IPv4 and IPv6 on a VPS: what you actually get

Read provider statements about IPv4 and IPv6 without assuming dual-stack, and know which questions to ask before you buy.

Last reviewedOct 24, 2026 · 1033 words

Two address families, two different questions

IPv4 and IPv6 are separate networking questions, and providers answer them with very different levels of clarity. The question is not only whether a plan supports IPv6, but whether an address is included by default, how large the allocation is, whether IPv4 costs extra, and whether the provider documents the gateway and prefix you will actually receive. A VPS that 'supports IPv6' can still ship with IPv6 disabled at provisioning time, and a plan with a public IPv4 address may bill that address separately from the instance price.

This guide uses only provider-published facts from the VPSTab catalog, captured with dates and sources. Where a provider does not state a field, VPSTab records it as unknown instead of assuming dual-stack. That distinction matters: an unverified field cannot satisfy a hard requirement in a recommendation, and it should not satisfy your own requirement either.

What included-by-default looks like

DigitalOcean documents that Droplets receive an IPv4 address by default and that IPv6 can be enabled for free in supported regions. The address is a single /128 per Droplet rather than a routed prefix, which is fine for a web service but not for a network that needs to address many containers or virtual machines behind the host. If you plan to run a VPN endpoint or a hypervisor, a single /128 limits how you hand out addresses internally.

Linode (Akamai Cloud) assigns IPv6 addresses automatically to compute instances and documents a /128 plus a /64 routed prefix in most regions, which is materially different from DigitalOcean's single address. Hetzner publishes a /64 per cloud server and states in its FAQ that the IPv4 address is billed as an add-on to the base price, which is why VPSTab records Hetzner offers with the IPv4 add-on included in composite figures. BuyVM documents an IPv6 /48 per KVM slice with per-location gateways, the largest allocation in this dataset, which is useful when you want to segment a network without requesting more space.

When IPv6 is optional or not included

Liquid Web's cloud VPS configurator lists IPv6 as an optional /64 rather than part of the default configuration, so VPSTab records IPv6 inclusion as false for those plans instead of treating them as dual-stack. That does not mean the plan is wrong for everyone; it means a buyer who needs IPv6 must verify the option and its price at checkout.

Several providers in the catalog publish prices and specifications but do not state IPv6 status on the captured pages. Vultr's plans API, for example, exposes CPU, RAM, disk, bandwidth and price but not address assignment, so VPSTab records IPv6 as unknown for all Vultr plans. Kamatera's preset cards similarly do not state IPv4 or IPv6 allocation. The honest answer for those offers is 'check with the provider', not 'probably yes'.

Mail servers, VPNs and certificates

A mail server needs a stable public address with a matching reverse DNS record. Those are operational requirements the provider must support, and they are separate from whether an address is included. A /64 prefix does not by itself give you reverse DNS for every address; you configure rDNS through the provider's panel or API and confirm that the provider allows it on the plan you bought. A VPN gateway has a similar constraint: clients need a reachable address family, and if you want dual-stack clients you need both families on the endpoint, not only on the server's outbound path.

TLS certificates and public DNS are unaffected by the address family as long as the name resolves to an address the server actually holds. The practical risk is assuming a new VPS 'will have IPv6' and discovering after provisioning that the prefix is missing, routed incorrectly, or blocked by an upstream firewall. Provision one instance, verify the address with a simple outbound and inbound test, and only then migrate a production name to it.

Costs that hide in the address line

Hetzner is the clearest example in this catalog: its price API quotes the server without the primary IPv4 address, and the address is billed separately, which is why the dataset uses the IPv4-inclusive composite for Hetzner offers and says so in the limitations. OVHcloud prices VPS plans with a primary IPv4 included in the stated offer; additional addresses are separate products. BuyVM includes one IPv4 with each slice and documents a /48 IPv6 allocation at no extra cost. These differences mean a simple table comparing monthly price can be wrong by a few dollars per year if the address is billed separately.

When you compare plans, compare the inclusive price: instance, required primary IPv4, and any mandatory setup fee. If a provider does not state whether the IPv4 is included, treat the total as unknown rather than assuming the lower figure. VPSTab's comparison view normalizes recorded prices to USD and flags when the tax scope or billing period differs, but it cannot invent an address fee that the provider does not publish.

A verification sequence before you commit

First, decide whether you need IPv4, IPv6, or both as hard requirements. Second, check the provider's documentation for the allocation size and default state. Third, confirm the price of any address add-on in the checkout or price API. Fourth, provision a minimal instance and verify inbound reachability for each family you need, plus reverse DNS if you run mail. Fifth, keep the verification date in your notes so a future price or policy change is visible.

For a buyer who wants a shortlist quickly, VPSTab's IPv6 filter distinguishes confirmed support from unknown data instead of silently treating unknown as yes, and the comparison page shows unknown fields as unknown. That is slower than assuming dual-stack, but it prevents the most common failure: buying a plan that cannot run the workload at all.

Verification checklist

  • Decide whether IPv4, IPv6 or both are hard requirements before comparing plans.
  • Check the allocation size (single address, /64, /48) rather than only 'supports IPv6'.
  • Confirm whether a primary IPv4 is included or billed as an add-on.
  • Verify reverse DNS support if the workload is a mail server.
  • Provision and test inbound reachability before moving a production name.
  • Treat unstated address fields as unknown, not as included.

Sources