IPv4 vs IPv6-Only VPS: Compatibility Checklist
An actionable IPv6 only VPS checklist covering visitors, DNS, IPv4 egress, software dependencies, administration, firewall rules, and fallback.
Facts that can change should include a source and check date. Benchmark claims should state the plan, region, method, and test period.
Short answer#
An IPv6-only VPS is suitable only when your visitors, administrators, and critical software dependencies support IPv6, or when the provider supplies the required translation and IPv4-facing services. For a public website or application with an unknown audience, dual-stack access is the safer default.
Check how visitors will connect#
An IPv6-only VPS is not automatically reachable by IPv4-only visitors. If those visitors must access the service, put an IPv4-facing proxy, load balancer, translator, or separate IPv4 endpoint in front of the VPS. Confirm that this component forwards the required ports and protocols to the IPv6 service.
A public service serving both networks needs an IPv4 path and an IPv6 path. If the provider offers no IPv4 endpoint or compatibility layer, IPv4-only users will not be able to connect.
Check DNS#
An A record identifies an IPv4 address. An AAAA record identifies an IPv6 address. For a dual-stack service, AAAA should point to the IPv6 service and A should point to an IPv4 service or compatibility layer when one is required. See Amazon Route 53 concepts for these record roles.
Do not add an A record pointing at an IPv6 address; the address families are different. Confirm which endpoint answers on each record and whether the provider manages the IPv4-facing layer.
Check outbound IPv4 access#
An IPv6-only server can reach IPv4-only destinations when the provider supplies DNS64 and NAT64, or an equivalent IPv4 egress service. DNS64 synthesizes an IPv6 answer from an IPv4 A record, and NAT64 translates the resulting connection. Google documents this model for IPv6-only workloads in Configure IPv6-only subnets and instances with DNS64 and NAT64.
Confirm that the service applies to your VPS and test the actual destinations your system needs: package repositories, APIs, databases, mail services, monitoring, licensing systems, and update services. DNS64/NAT64 does not reliably help software that uses literal IPv4 addresses or APIs that are not IPv6-compatible. If a tool connects directly to a hard-coded IPv4 address, it may bypass the DNS step entirely. The limitations are discussed in RFC 8683.
Compatibility checklist#
| Check | Pass condition |
|---|---|
| Visitors | IPv4-only users have an IPv4-facing endpoint, proxy, or translator. |
| DNS | AAAA points to the IPv6 service; A points to an IPv4 service or compatibility layer when needed. |
| Outbound connections | The provider confirms DNS64/NAT64 or equivalent IPv4 egress. |
| Software dependencies | Package repositories, APIs, databases, mail, monitoring, licensing, and update services support IPv6 or use translatable hostnames. |
| IPv4 literals | No critical tool depends on hard-coded IPv4 addresses without a documented workaround. |
| Administration | SSH or control-panel access works from the administrator’s network, or a console or relay is available. |
| Firewall | Required ports are allowed in the IPv6 firewall or security group. |
| Future fallback | The provider can add IPv4 or place a dual-stack front end in front of the VPS. |
Decide after the checks#
Choose an IPv6-only VPS when every required user and dependency passes the checklist, or when the provider has confirmed the necessary IPv4 compatibility services. Choose dual-stack access when the audience is unknown, a critical dependency has not been tested, or administration depends on networks that may be IPv4-only.
If the provider cannot confirm inbound IPv4 access, IPv4 egress, and a workable fallback, do not assume the missing pieces will work later. Keep the service dual-stack or select a provider that can supply the required compatibility layer. RFC 7755 describes translation approaches for IPv4 clients reaching IPv6-only services.
Sources
- Amazon Route 53 concepts Checked 2026-09-18
- Google Cloud: Configure IPv6-only subnets and instances with DNS64 and NAT64 Checked 2026-09-18
- IETF RFC 8683: NAT64/464XLAT deployment guidelines Checked 2026-09-18
- IETF RFC 7755: SIIT-DC Checked 2026-09-18