IPv6-only deployment — when you can skip IPv4 (and when you can't)

IPv4 is exhausted; IPv6 has been ready for decades. Yet the internet remains stubbornly dual-stack because some destinations still don't have IPv6. This article covers when an IPv6-only VPS is realistic, when it isn't, and what bridging options exist.

The honest current state

As of 2026:

• ~50% of global traffic to large content providers (Google, Facebook, etc.) is IPv6.
• The other ~50% is still IPv4. Mostly because some client-side networks (corporate, hotel, airline wifi) don't run IPv6 yet.
• Most server-side services have IPv6 — but not all. Notable gaps: some package mirrors, some VoIP carriers, some older API endpoints.

Pure IPv6-only servers work when the server's job is to be reached by clients (which mostly have IPv6) — but break when the server itself needs to reach IPv4-only destinations.

When IPv6-only works fine

• You're providing services to consumers on residential ISPs with IPv6 (most North American and European ISPs in 2026).
• Your application talks only to other modern services (Google APIs, AWS endpoints, modern CDNs — all dual-stack).
• You can put a CDN or proxy in front that handles dual-stack for you (Cloudflare, Fastly, Bunny).

When IPv6-only breaks

• SMTP delivery to IPv4-only receivers. Some smaller mail servers still don't accept IPv6 connections.
• Outgoing API calls to legacy services. Older B2B integrations, some payment processors, some SIP carriers.
• SSH from corporate/hotel networks. Many client networks block IPv6 to outbound; you can't reach your own server from such a network.
• Package mirrors. Some Linux distro mirror infrastructure is still IPv4-only or has intermittent IPv6 issues.

The bridging options

NAT64 + DNS64

A network-side translator that synthesizes IPv6 representations of IPv4 destinations. Your IPv6-only VPS gets a DNS response that points to an IPv6 address; the NAT64 gateway translates to the real IPv4 destination.

Several public NAT64 services exist (some free, some paid). LYLIX doesn't currently provide a managed NAT64, but the technique works fine with public ones.

464XLAT

A client-side complement to NAT64 — looks like the IPv4 endpoint to applications that can't speak IPv6. More commonly seen in mobile networks than VPS deployments.

Just keep one IPv4 for outbound

The pragmatic option: dual-stack the VPS. You get an IPv6 for inbound (your primary service exposure) and one IPv4 specifically for outbound reachability. This sidesteps NAT64 complexity for one IPv4 charge.

Cost trade-off

• IPv6 is free at LYLIX (and most hosts).
• IPv4 is billable per IP per month. See Ordering additional IPv4.

For a service that doesn't need IPv4 inbound (because your clients reach you via Cloudflare, or because you don't have IPv4 clients), skipping the IPv4 address saves a small monthly fee per VPS. Multiply by VPS count, and it adds up.

Configuration on a LYLIX VPS

If you've ordered with IPv6 only, the VPS gets a /64 (vast) or smaller block. Configure on Debian/Ubuntu via netplan:

network:
  ethernets:
    eth0:
      addresses:
        - 2001:db8::1/64
      gateway6: 2001:db8::1
      nameservers:
        addresses:
          - 2001:4860:4860::8888
          - 2606:4700:4700::1111

On AlmaLinux/Rocky via NetworkManager nmcli — same idea but the NM connection model.

Service configurations to verify

• nginx: listen [::]:443 ssl; binds to all IPv6 interfaces. Add listen 443 ssl; too if you have IPv4.
• Postfix: inet_protocols = ipv6 or = all.
• SSHD: ListenAddress :: in /etc/ssh/sshd_config.
• Application binds — many apps default to 0.0.0.0 (IPv4 only). Look for IPv6 bind options.

DNS

• Publish AAAA records for your services. Without these, IPv6 clients can't find you.
• Don't publish an A record if you don't have an IPv4 — otherwise clients try IPv4 first, fail, then fall back to IPv6 with a noticeable delay.
• If you ever need to revert to dual-stack, you'll publish A again at that point.

SSH access

Many client networks (especially in corporate environments) have IPv4 but no IPv6. You can't SSH to an IPv6-only server from them.

Mitigations:

• Always have a backup access path — the LYLIX browser console works regardless of IPv6 availability on the client side.
• Use a jumpbox with dual-stack connectivity that you SSH into first.
• Cloudflare Tunnel or similar exposes an SSH-over-HTTPS endpoint reachable from anywhere.

Reverse DNS

IPv6 PTR records work the same way as IPv4. LYLIX manages IPv6 PTR via support ticket (the portal's Reverse DNS tab currently handles IPv4 only). See Reverse DNS.

The recommendation

For most production workloads in 2026, dual-stack remains the safe default. IPv6-only is workable for:

• A test/dev VPS where the small cost saving matters.
• A VPS sitting behind a dual-stack CDN, where the origin only needs to be reachable from the CDN's IPv6.
• A pure-internal compute node that doesn't need outbound internet access at all.

For everything else, save the headache and order with IPv4 + IPv6 both. The IPv4 is cheap enough that "avoiding the cost" isn't usually worth the friction.