Static IPv6 Setup on a Linux VPS

IPv6 adds a native connectivity option to your VPS for users on IPv6-capable networks. Dual-stack (IPv4 + IPv6) lets you offer that option while retaining IPv4 access. It does not automatically improve routing, performance, or email deliverability; those outcomes depend on your network paths and service configuration. In this guide we will walk through, step by step, how to configure static IPv6 on a Linux VPS using Netplan, ifupdown or NetworkManager, test that it really works end-to-end, secure it with a proper firewall, and wire it into your DNS and email stack while preserving existing IPv4 access.

Why Add IPv6 to Your VPS?

Before we dive into configs, it is important to understand why you are investing time in IPv6 at all. The short version: IPv4 addresses are scarce and expensive, while IPv6 provides a vastly larger address space. Routing quality and performance depend on the networks involved, not just the IP version.

If you have been following our articles on the period of record IPv4 address prices and global IPv6 adoption, consider your own audience and network paths. IPv6 adoption varies by country and access network, and many modern CDNs and managed DNS services support IPv6.

For your VPS, enabling IPv6 means:

• Better reachability to users on IPv6-only or IPv6-preferred networks.
• Long-term flexibility as IPv4 pricing and availability change, though dual-stack still requires IPv4 addresses.
• More addressing flexibility for microservices or multi-region architectures, subject to your provider’s allocation and routing.
• IPv6 email transport to compatible mail servers; enabling it alone does not improve deliverability.

The configuration examples below assume that your provider has confirmed IPv6 availability for your VPS, assigned usable address and routing details, and provided console access. Confirm those details for your dchost.com plan and location before making changes.

IPv6 Basics for VPS Owners: What You Actually Need to Know

You do not need to become a network engineer to use IPv6 on your VPS, but a few key concepts will make the configuration steps much easier to understand.

IPv6 address format and compression

An IPv6 address is 128 bits, written as eight groups of four hexadecimal digits, separated by colons. Example:

2001:db8:1234:abcd:0000:0000:0000:0001

Zeros can be compressed for readability:

• Leading zeros in each group can be omitted: 0001 → 1.
• One continuous run of :0000: groups can become ::.

So the address above becomes:

2001:db8:1234:abcd::1

Prefixes and subnets

IPv6 uses CIDR notation to express networks. A /64 is one example; use the interface prefix specified by your provider rather than assuming every VPS receives the same allocation.

• 2001:db8:1234:abcd::/64 has a 64-bit network prefix and is part of the documentation-only 2001:db8::/32 range. These examples cannot be used for public connectivity.
• Your provider may assign individual addresses or a routed block. Use only your assigned addresses and the routing model supplied for your VPS.

Dual-stack vs IPv6-only

With dual-stack, your VPS has both IPv4 and IPv6 connectivity, and the intended services listen on both families. This preserves access for IPv4-only clients while adding IPv6; it requires testing both paths rather than assuming one successful test covers both.

IPv6-only setups are possible. NAT64/DNS64 can help IPv6-only clients reach IPv4 services, but does not by itself let IPv4-only visitors reach an IPv6-only website; that needs an IPv4-capable frontend such as a reverse proxy. We covered this in detail in our article on running a website on an IPv6-only VPS. For now, assume you are targeting dual-stack.

Link-local and global addresses

Your server will often have:

• Link-local address (reserved prefix fe80::/10; commonly shown starting with fe80::) – used for communication on the local link only, not routed on the internet.
• Global unicast address – your provider-assigned public address, subject to its routing. The abbreviated 2a01:4f8:... is not a complete address; use your actual allocation for DNS.

Use the global address confirmed for your VPS. If the dchost.com panel does not show all required details, obtain them from support before continuing.

Prerequisites: What You Need Before Configuring IPv6

Before touching configuration files, verify these prerequisites. Missing provider support, address details, or firewall rules can prevent IPv6 connectivity.

1. IPv6 support in your VPS plan

IPv6 availability depends on the provider, location, and plan. For your dchost.com VPS, confirm the following:

• IPv6 is enabled at the data center network level.
• Your VPS has at least one IPv6 address and gateway assigned.
• Security groups/firewall templates have IPv6 rules configured.

If you are not sure, open a ticket with our support team and ask for the IPv6 details for your VPS.

2. Operating system support

Recent mainstream Linux distributions generally support IPv6 in their standard kernels (Ubuntu, Debian, Rocky Linux, AlmaLinux, etc.). Image settings can still disable it. Potential problems include:

• IPv6 disabled on the intended interface via sysctl or at boot with ipv6.disable=1. Check the interface-specific net.ipv6.conf.ens3.disable_ipv6 value; reading all.disable_ipv6 alone does not establish interface state. The boot-time disable parameter requires correction and a planned reboot.
• Multiple network configuration tools trying to manage the same interface (e.g., ifupdown and Netplan).
• Firewall rules that allow IPv4 but drop all IPv6 traffic.

3. DNS and control over records

You will need the ability to edit your domain’s DNS records to add AAAA records. IPv6 PTR records belong to a separate reverse-DNS zone, normally controlled by the IP provider; request them through the provider unless reverse DNS has been delegated to you. If you are not fully comfortable with DNS yet, our article explaining DNS records like a friend is a great warm-up.

Finding Your IPv6 Details in the dchost.com Panel

Check your dchost.com control panel for the following IPv6 details. If any are missing, request them from support before configuring a static address:

• Global IPv6 address for the VPS (e.g. 2001:db8:1234:abcd::10).
• Prefix length (for example /64; use the assigned value).
• Gateway address (e.g. 2001:db8:1234:abcd::1).
• IPv6 DNS resolvers (provider-supplied, if available, or public resolvers).

We will plug these details into your network configuration files in the next section.

Configuring IPv6 on Popular Linux Distributions

The exact configuration depends on your distro and networking stack. Below you will find common approaches for Ubuntu/Debian and Rocky/AlmaLinux (RHEL clones). Adjust interface names (eth0, ens3, enp1s0, etc.) to match your VPS. The 2001:db8::/32 addresses below are documentation placeholders, not usable public addresses. Use only addresses and prefixes assigned to you. These static examples assume one uplink with an on-link gateway and manually configured IPv6 address and default route. A gateway such as fe80::1 is link-local and must be associated with the correct interface. Follow your provider’s instructions if it uses SLAAC, DHCPv6, /128 addresses or a different routing setup.

Use only the method that manages your interface. Back up the existing configuration and confirm console or rescue access before applying changes: a network restart or incorrect configuration can disconnect SSH. Merge the IPv6 settings into your working configuration rather than replacing it, preserving existing IPv4 addresses, routes, and DNS settings.

Ubuntu or Debian systems managed by Netplan

Use this method only if Netplan manages the interface. Check the existing renderer (systemd-networkd or NetworkManager) and all files under /etc/netplan/; do not create a second conflicting definition for the same interface. The example below uses networkd, IPv4 DHCP and fully static IPv6.

1. Find your Netplan config file, e.g.:

   ls /etc/netplan/

2. Edit the YAML file, for example /etc/netplan/50-cloud-init.yaml. If it is marked as generated, follow the image’s instructions for making persistent changes:

network:
  version: 2
  renderer: networkd
  ethernets:
    ens3:
      dhcp4: true
      dhcp6: false
      accept-ra: false
      addresses:
        - 2001:db8:1234:abcd::10/64
      routes:
        - to: "::/0"
          via: 2001:db8:1234:abcd::1
      nameservers:
        addresses:
          - 2001:4860:4860::8888
          - 2001:4860:4860::8844

Replace the IPv6 address, prefix and gateway with the ones from your dchost.com panel. Keep dhcp4: true only if your existing IPv4 setup uses DHCP; otherwise preserve your current static IPv4 configuration instead of adopting the example’s DHCP setting. Preserve your existing renderer, routes and DNS list as well; the public resolvers shown are examples. dhcp6: false disables DHCPv6, while accept-ra: false separately disables Router Advertisement acceptance. Use these settings only for the fully static setup described above. The routes entry replaces the deprecated gateway6 key; an AAAA lookup does not itself require an IPv6 DNS transport.

3. Generate the configuration to check for errors, then start a timed trial with console access available:

sudo netplan generate
sudo netplan try --timeout 120

netplan try applies the configuration and waits for confirmation. Check IPv4 and IPv6 from a second connection before confirming; without confirmation, it attempts to revert after the timeout. Netplan documents rollback bugs, so verify both connectivity and the files on disk from the console if it times out or is cancelled. sudo netplan apply has no timed confirmation. Inspect the address and route below, then repeat the checks after a planned reboot to confirm persistence:

ip -6 addr show dev ens3
ip -6 route

Debian with ifupdown (/etc/network/interfaces)

Use /etc/network/interfaces and its included files only when ifupdown manages this interface. Merge the IPv6 stanza into the working configuration, preserving loopback, IPv4 and DNS definitions. The sample assumes IPv4 DHCP and fully static IPv6; do not replace a static IPv4 configuration with it.

auto ens3
iface ens3 inet dhcp

iface ens3 inet6 static
    address 2001:db8:1234:abcd::10/64
    gateway 2001:db8:1234:abcd::1
    accept_ra 0

Here accept_ra 0 matches the manually supplied gateway; do not use it unchanged on a network that learns its route from Router Advertisements. With the configuration backed up and console access available, restart the ifupdown networking service to apply it. This can interrupt SSH:

sudo systemctl restart networking

RHEL, Rocky Linux and AlmaLinux with NetworkManager

On RHEL-like systems using NetworkManager, use nmcli. Editing an ifcfg file is an alternative only where that format is supported by the installed version and already used for the connection.

Using nmcli

nmcli connection show

Find the connection profile for your uplink; System eth0 is only an example name and need not match the device name. Substitute the actual profile name, or use its UUID if names are duplicated. Replace the documentation address, prefix and gateway with your allocation. These commands change IPv6 properties only; merge with any existing IPv6 address/route settings and preserve required DNS servers. Check that ipv6.never-default is not enabled and that another default route does not conflict. Have console access available before reactivation, which may disconnect SSH.

sudo nmcli connection modify "System eth0" \
  ipv6.method manual \
  ipv6.addresses 2001:db8:1234:abcd::10/64 \
  ipv6.gateway 2001:db8:1234:abcd::1

sudo nmcli connection up "System eth0"

Legacy ifcfg files where supported

RHEL 9 can still read pre-existing ifcfg profiles; RHEL 10 removed this format. Check the installed release and ifcfg-rh plugin support on derivatives as well. Use this alternative only if NetworkManager already manages your connection through an existing file such as /etc/sysconfig/network-scripts/ifcfg-eth0. Back it up and merge the IPv6 settings; retain the real DEVICE, BOOTPROTO, ONBOOT, IPv4 and connection identity values. The snippet assumes IPv4 DHCP and static IPv6.

DEVICE=eth0
BOOTPROTO=dhcp
ONBOOT=yes

IPV6INIT=yes
IPV6_AUTOCONF=no
DHCPV6C=no
IPV6ADDR=2001:db8:1234:abcd::10/64
IPV6_DEFAULTGW=2001:db8:1234:abcd::1

If you used the legacy file method, load the edited file into NetworkManager, then reactivate the correct profile. Loading alone does not apply the new settings to the active connection. Substitute your actual filename and profile name; reactivation can interrupt SSH, so use the prepared console access:

sudo nmcli connection load /etc/sysconfig/network-scripts/ifcfg-eth0
sudo nmcli connection up "System eth0"

Check basic IPv6 connectivity

Regardless of distribution, once configured you should verify that you can reach the internet over IPv6:

ping -6 -c 4 google.com
ping6 -c 4 ipv6.google.com
curl -6 https://ifconfig.co

Successful pings and an IPv6 address returned by curl confirm outbound IPv6 connectivity to those destinations. They do not verify inbound access to your VPS services. If ping6 is unavailable, use ping -6. Missing echo replies alone do not prove a routing failure, since a destination may filter them.

Testing, Troubleshooting, and Common IPv6 Pitfalls

Getting an IPv6 address on the interface is only half the story. Check that the assigned global address is not marked tentative or dadfailed; these indicate pending or failed Duplicate Address Detection. You also need to confirm routing, DNS, and firewall behaviour.

Verify routing

Check the default IPv6 route:

ip -6 route show default

You should see a line similar to:

default via 2001:db8:1234:abcd::1 dev ens3 proto static

Without a default route, destinations not covered by a more specific route are unreachable. Re-check your gateway configuration.

Validate DNS resolution over IPv6

Test a DNS query to Google Public DNS over IPv6. This explicitly selects that resolver rather than testing your system’s configured resolver:

dig aaaa www.dchost.com @2001:4860:4860::8888

A DNS response confirms communication with the selected resolver, but check the answer section to see whether an AAAA record was returned. If this query succeeds but normal hostname lookups fail, inspect /etc/resolv.conf and the system’s resolver configuration. If the file is generated, fix the owning network/resolver service rather than editing it blindly. Querying an AAAA record can use either IPv4 or IPv6 transport; a DNS answer does not prove reachability of the returned address.

Check for firewall blocks

IPv4 firewall rules may be correct while IPv6 traffic is blocked. Inspect IPv6 rules, counters and logs, including any provider firewall. If a temporary test rule is needed, restrict it to the test source and required service, then remove it after testing rather than accepting all IPv6 traffic.

If you are using nftables, our detailed guide on IPv6-aware nftables firewall configuration walks through example rule sets to adapt to your services.

Browser and external tests

Before publishing an AAAA record, test from an external IPv6-enabled workstation or VPS. Use your actual hostname and allocated address with a direct probe that preserves the hostname for TLS and SNI:

curl -6 --noproxy '*' --resolve 'example.com:443:[2001:db8:1234:abcd::10]' https://example.com/

A literal-IP HTTPS URL can fail certificate or virtual-host checks even when routing works. Keep certificate verification enabled. If a CDN is involved, test its public client path separately from this direct-origin test. After DNS publication, continue with:

• Visiting online test sites that confirm if your domain and IP are reachable over IPv6.
• Using curl -6 https://yourdomain.com from another IPv6-enabled VPS or workstation.
• Running traceroute6 yourdomain.com to inspect responding hops; missing replies are not conclusive. Compare curl -4 and curl -6 without disabling either family on the server.

Securing IPv6: Firewall and Hardening Essentials

IPv6 does not magically make things more or less secure than IPv4; the same principles apply. What trips people up is forgetting to apply their security model to IPv6 at all.

Apply a dual-stack firewall policy

Apply equivalent access restrictions to services you intend to expose over both IPv4 and IPv6, including any source-address restrictions for SSH or custom app ports. Deny unwanted traffic while allowing necessary control traffic such as ICMPv6. For example, nftables supports an inet table for both families. The input-chain example below assumes a simple VPS with one uplink, no routing/container network, and no separate output restriction. Adapt interface names, SSH port and source restrictions to your policy; do not replace a running ruleset blindly. The IPv4 DHCP rule supports the earlier DHCP examples; omit it for static IPv4. Uncomment the DHCPv6 rule only if your connection requires that client traffic.

table inet filter {
  chain input {
    type filter hook input priority 0;

    ct state established,related accept
    iifname "lo" accept
    iifname "ens3" meta nfproto ipv4 udp sport 67 udp dport 68 accept
    # Enable only when using DHCPv6:
    # iifname "ens3" meta nfproto ipv6 udp sport 547 udp dport 546 accept

    tcp dport { 22, 80, 443 } accept
    icmp type echo-request accept
    meta l4proto ipv6-icmp accept

    reject with icmpx type admin-prohibited
  }
}

meta l4proto ipv6-icmp matches ICMPv6 beyond extension headers; ip6 nexthdr only checks the immediately following header. This simple baseline accepts all ICMPv6, not just ping. Blocking it entirely can break neighbour discovery and Path MTU Discovery, including Packet Too Big messages. For a narrower policy, follow the message-type and scope guidance in RFC 4890. Other tables and chains can still drop traffic; check the merged configuration, apply it with console recovery available, and verify external access.

General VPS security

Enabling IPv6 should be part of a broader hardening plan. If you have not already, follow our checklist in how to secure a VPS server to lock down SSH, users, and services. The same hardening principles apply, but verify that address-based rules and network controls also cover IPv6.

Application-level configuration

Enabling IPv6 on the interface does not ensure that applications listen on it. Review your service configurations:

• Nginx: add listen [::]:80; to the existing HTTP server block while retaining its IPv4 listener. For HTTPS use listen [::]:443 ssl; in the existing TLS block, alongside its certificate and private-key configuration. A bare listen [::]:443; does not enable TLS. Check the merged configuration with sudo nginx -t before reloading.
• Apache: Listen opens sockets and <VirtualHost *:80> selects the site. A single Listen 80 can serve both families with an IPv6-capable build; confirm actual sockets and external IPv4/IPv6 access. Do not blindly add Listen [::]:80 beside it, since overlapping listeners can prevent startup. HTTPS also needs an SSL-enabled virtual host, certificate and key. Use the package’s configuration test and virtual-host listing before applying changes.
• Mail servers: configure Postfix/Exim/Dovecot listeners for the protocols and address families you actually intend to expose. Outbound mail uses separate routing and sender-policy checks.
• Databases: enable IPv6 listeners only if needed and restrict access to authorized clients; an internal database does not need a public listener.

IPv6 and DNS: AAAA Records, Reverse DNS, and Email

Once your VPS services are reachable over IPv6, publish the appropriate DNS records so clients can discover their IPv6 addresses by hostname. Preserve working A records, verify the returned answers and repeat external HTTPS tests. If you change or remove an AAAA record during rollback, caches may retain the old answer until its previous TTL expires.

Adding AAAA records

For each hostname you want reachable over IPv6 (e.g. example.com, www.example.com):

• Create an AAAA record pointing to your server’s IPv6 address.
• Keep your existing A record so IPv4 users can still connect.

We have a dedicated deep dive on this topic in our no-drama dual-stack AAAA record playbook, including real-world testing strategies.

Reverse DNS (PTR) for IPv6

IPv6 reverse DNS uses the ip6.arpa domain. The IP provider normally controls that zone; use its PTR workflow or ask support unless reverse DNS has been delegated to you. Domain DNS access by itself does not grant control of the provider’s reverse zone.

• Choose the IPv6 address assigned to your VPS.
• Set the PTR / reverse hostname (e.g. vps1.example.com).

This is particularly important for email servers.

Email deliverability over IPv6

If you run your own mail server, check the receiving providers’ IPv6 requirements before enabling outbound IPv6 mail. At a minimum:

• Arrange a PTR record for the sending IPv6 address. The PTR hostname should have an AAAA record pointing back to that address (forward-confirmed reverse DNS). Use a valid, resolvable HELO/EHLO hostname; using the same name is a sensible consistency choice, but exact PTR/HELO equality is not a universal SMTP requirement.
• Authorize the sending address or infrastructure in SPF, for example through an ip6: mechanism. DKIM signs messages and DMARC checks aligned authentication and policy; their records do not list sending IP addresses.
• An MX target needs AAAA when you intend to receive mail at that host over IPv6; merely sending outbound over IPv6 does not require adding AAAA to MX targets.
• Check receiving-provider rules, port 25 reachability and address reputation. Monitor blocklists, but do not assume IPv6 itself improves deliverability or fixes a listing.

We have a separate, practical guide on this: Email deliverability over IPv6: PTR, HELO, SPF and blocklists. If you plan to send any serious volume of mail, read that before flipping the switch.

Monitoring IPv6 on Your VPS in Production

Once IPv6 is live, you want your monitoring to treat it as a first-class citizen. Monitoring only IPv4 can miss an IPv6 outage, and the reverse is also true.

Dual-stack uptime checks

For each critical endpoint, configure:

• At least one probe that resolves an A record and connects over IPv4.
• At least one probe that resolves an AAAA record and connects over IPv6 without falling back to IPv4.

This can be done with self-hosted tools or external monitoring services. Our article on VPS monitoring and alerts with Prometheus, Grafana and Uptime Kuma is a good starting point if you want to run this stack yourself on a dchost.com VPS.

Log analysis and observability

Ensure your logging stack correctly parses IPv6 addresses:

• Web server logs should show IPv6 client IPs without truncation.
• WAF and intrusion detection rules should be IPv6-aware.
• Any IP-based rate limiting or abuse detection should support both families.

Audit IP-based rate limits and access controls for IPv6 parsing and address/prefix handling. Test the expected policy on both families; merely accepting a longer address string does not prove equivalent enforcement.

When to Consider IPv6-Only on a VPS

IPv6-only deployments can avoid an IPv4 allocation on some workloads, but translation, proxy services and application compatibility affect total cost. Plan both incoming users and outgoing dependencies before choosing this model. Panel-specific requirements also apply; cPanel & WHM requires at least one IPv4 address.

Pros of IPv6-only

• Internal services may avoid individual IPv4 allocations when all required clients support IPv6.
• A large address space provides allocation flexibility, subject to the provider’s routing and prefix assignment.
• An environment you control can be used to validate application and monitoring support before a wider rollout.

Challenges and mitigation

One challenge is talking to IPv4-only services (legacy APIs, payment gateways, some email providers). NAT64/DNS64 can bridge IPv6-only clients to IPv4 destinations, though applications that depend on IPv4 literals or IPv4-only sockets may need additional compatibility mechanisms. Public IPv6-only services also need an IPv4-capable frontend if they must serve IPv4-only clients; the outbound bridge does not by itself provide that inbound access. In our detailed story on IPv6-only VPS with NAT64/DNS64, we discuss the translation model and its deployment considerations. Confirm that any required NAT64/DNS64 or IPv4 frontend service is available from your chosen provider.

Choose the model according to your reachability requirements:

• Start with dual-stack for internet-facing services.
• Use IPv6-only for internal microservices or lab environments where you control both ends.
• Plan IPv6-only public deployments only after you are comfortable with the operational model.

Summary and Next Steps with dchost.com

A complete IPv6 deployment combines confirmed provider details, persistent settings in the active network manager, correct routing, appropriate firewall rules and services listening on IPv6. Verify external IPv4 and IPv6 access before publishing AAAA records, then check DNS answers, TLS and application behaviour again. Repeat address, route and service checks after a planned reboot. PTR and mail authentication need separate attention when sending email.

When choosing a VPS, dedicated server or colocation arrangement with dchost.com, confirm IPv6 support for the location and plan, allocation and gateway details, and console access. Adapt these examples to that information and your operating system’s active network manager.

If you want to go deeper, we recommend reading our dual-stack DNS guide on AAAAs and real-world tests, our IPv6 email deliverability playbook, and the nftables firewall cookbook for IPv6-aware security. Keep configuration backups and a rollback plan, and monitor IPv4 and IPv6 separately so fallback cannot hide a broken IPv6 path.