IPv4, IPv6, and Dual-Stack Networking for Cloud Servers

IPv4, IPv6, and dual-stack describe how a cloud server is addressed and reached across modern networks.

IPv4 remains the broadest compatibility baseline. IPv6 provides a much larger address space and cleaner long-term network planning. Dual-stack lets a service use both, but only works well when DNS, firewall rules, application listeners, and monitoring are configured for both address families.

For most public applications, the safest path is not an immediate IPv6-only cutover. It is a staged rollout: keep IPv4 available, add IPv6 where the platform and application path support it, test both independently, and publish both DNS records only after the complete route works.

IPv4 vs IPv6 vs dual-stack: quick answer

Choose IPv4-only when broad compatibility and operational simplicity matter more than immediate IPv6 adoption.

Choose dual-stack when you want to support both IPv4 and IPv6 clients without forcing a hard migration.

Choose IPv6-only only when every client, dependency, monitoring service, and administrative path is known to support IPv6 or when translation is deliberately part of the design.

A useful rule is:

Do not publish an AAAA record until the IPv6 path works end to end. DNS should advertise a working route, not an intended future state.

What IPv4 means for a cloud server

IPv4 uses 32-bit addresses such as:

203.0.113.20

It remains widely supported by browsers, enterprise networks, monitoring providers, partner systems, allowlists, and operational tooling.

IPv4 is often the simplest starting point for:

• public websites
• APIs with third-party consumers
• services used by older corporate networks
• workloads that depend on IPv4 allowlists
• teams that have not yet tested IPv6 operations

Its limitation is address scarcity. Public IPv4 addresses are finite, and private IPv4 ranges can also become difficult to manage when environments, customers, VPNs, and internal networks begin to overlap.

NAT can extend IPv4 designs, but it also adds translation, state, and troubleshooting complexity.

What IPv6 changes

IPv6 uses 128-bit addresses such as:

2001:db8:1234:1::20

The larger address space is the obvious difference, but it is not the only operational change.

IPv6 affects:

• address planning
• DNS
• firewall policies
• service binding
• log formats
• monitoring
• access-control lists
• application libraries
• third-party allowlists

IPv6 does not remove the need for firewalls or least-privilege access. A globally routable address should not be treated as permission for the internet to reach the service.

The security model remains:

1. expose only required services
2. restrict source and destination traffic
3. authenticate users and services
4. monitor both expected and unexpected access

What dual-stack actually means

Dual-stack means the relevant server, network, or application path can use both IPv4 and IPv6.

For a public website, a simplified path looks like this:

Client
  ├─ IPv4 route → A record → IPv4 listener
  └─ IPv6 route → AAAA record → IPv6 listener

A complete dual-stack deployment may require support at every layer:

• the cloud platform assigns or routes IPv6
• the VM operating system configures the address
• the firewall allows the intended IPv6 traffic
• the reverse proxy or application listens on IPv6
• DNS publishes the correct AAAA record
• monitoring tests the IPv6 endpoint separately

A service is not operationally dual-stack merely because the operating system displays an IPv6 address.

Why broken IPv6 can affect users

Modern clients may receive both A and AAAA records and choose between multiple addresses. Algorithms such as Happy Eyeballs reduce delays by attempting suitable routes without waiting too long for a broken path.

That does not make bad IPv6 configuration harmless.

A partially working route can still create:

• slow connection attempts
• failures from specific ISPs or office networks
• monitoring disagreements
• TLS or proxy issues visible only over one address family
• support cases that appear intermittent

Test from real external IPv4 and IPv6 networks rather than relying only on local server checks.

DNS design for IPv4 and IPv6

A records

An A record maps a hostname to an IPv4 address.

app.example.com → 203.0.113.20

AAAA records

An AAAA record maps a hostname to an IPv6 address.

app.example.com → 2001:db8:1234:1::20

Dual-stack DNS

A dual-stack hostname usually publishes both:

app.example.com → A → 203.0.113.20
app.example.com → AAAA → 2001:db8:1234:1::20

Before publishing the AAAA record, verify:

• the address is assigned and routed correctly
• the service listens on the intended IPv6 socket
• TLS certificates and SNI behavior work
• firewall rules allow only the intended ports
• health checks pass over IPv6
• logs record the client address correctly
• upstream dependencies do not assume IPv4-only source addresses

DNS should be the final publication step after the network path is validated.

Firewall rules must cover both families

A common migration error is protecting IPv4 carefully while leaving IPv6 broader than intended.

Review IPv4 and IPv6 exposure separately.

For a web VM, the intended policy may be:

Do not assume a firewall tool automatically mirrors IPv4 rules to IPv6. Confirm the actual behavior of the operating system and platform firewall.

Private addresses also do not replace firewall policy. A private network limits reachability, while firewall rules define which reachable systems may communicate.

Application and reverse-proxy binding

Even when networking is configured correctly, the application may listen only on IPv4.

Common listener examples include:

0.0.0.0:443     IPv4 on all interfaces
[::]:443        IPv6 on all interfaces
127.0.0.1:3000  IPv4 loopback only
[::1]:3000      IPv6 loopback only

The exact behavior depends on the operating system and application runtime. On some systems, an IPv6 wildcard listener may also accept IPv4-mapped connections; on others, separate listeners are needed.

Verify the behavior rather than assuming it.

For reverse proxies such as Nginx, HAProxy, or Caddy, test:

• frontend IPv4 reachability
• frontend IPv6 reachability
• backend connection family
• original client-IP forwarding
• TLS termination
• health-check behavior

Read Reverse Proxy vs Load Balancer when deciding where the public listener should sit.

Public and private traffic are separate decisions

Public IPv6 adoption does not require every internal service to become publicly reachable.

A practical architecture may use:

Internet clients
  ↓ IPv4 or IPv6
Public load balancer or reverse proxy
  ↓ private network
Application servers
  ↓ private network
Database and internal services

The public edge may support both address families while backend communication stays on the private addressing model supported by the environment.

Use Private Networking in Cloud: Public vs Private Traffic to decide which components should be internet-accessible.

IPv4-only: when it remains reasonable

IPv4-only is still a valid choice when:

• your service must support the widest possible range of networks
• third-party allowlists accept only IPv4
• operational tooling has not been tested with IPv6
• your team needs the simplest initial deployment
• IPv6 does not yet solve a current constraint

The important point is to avoid creating unnecessary future barriers.

Keep configuration and application code flexible by:

• storing hostnames instead of hardcoded IP addresses
• supporting IPv6-safe log and database fields
• avoiding parsing logic that assumes dotted-decimal addresses
• reviewing libraries and access-control systems for IPv6 support

Dual-stack: when it is the better migration path

Dual-stack is a good fit when:

• the workload is public-facing
• both legacy and modern networks must connect
• the team wants gradual IPv6 adoption
• IPv6 routing is supported across the required platform path
• monitoring can validate each family independently

Dual-stack adds operational work because every exposed service has two potential paths. That added work is justified when compatibility and gradual adoption both matter.

IPv6-only: when to use it carefully

IPv6-only may work well for:

• controlled internal networks
• greenfield environments with known dependencies
• specialized services where clients are IPv6-capable
• architectures with a tested IPv4 translation layer

Before choosing IPv6-only, verify:

• package repositories and update systems
• identity providers
• external APIs
• monitoring and alerting services
• CI/CD runners
• DNS resolvers
• support access
• backup destinations

A single critical IPv4-only dependency can make an otherwise clean IPv6-only design unreliable.

Monitoring and observability

Monitor IPv4 and IPv6 as distinct service paths.

At minimum, test:

• DNS A response
• DNS AAAA response
• TCP connection over IPv4
• TCP connection over IPv6
• TLS handshake over both families
• application health response
• latency and error rate by address family

Logs and analytics should preserve valid IPv6 addresses. Database columns sized only for short IPv4 strings can truncate or reject IPv6 values.

For textual storage, allow enough space for normalized and non-normalized address representations or use a database-native IP address type where available.

A practical rollout plan

Stage 1: audit the path

Confirm platform support, VM configuration, firewall behavior, proxy listeners, DNS management, and monitoring capability.

Stage 2: test without public DNS

Reach the service directly over the assigned IPv6 address or use a temporary test hostname.

Stage 3: validate the application

Check authentication, redirects, callbacks, WebSockets, API clients, logs, and rate limiting.

Stage 4: publish the AAAA record

Add the IPv6 DNS record only after the path is stable.

Stage 5: monitor both families

Track failures separately and keep rollback simple: removing the AAAA record should be an available response to an IPv6-specific incident.

Stage 6: expand gradually

Move additional services only after the first deployment behaves predictably.

How this applies on Raff

Raff Private Cloud Networks are designed for isolated internal communication and the current product page lists flexible subnet support for IPv4 and IPv6.

Public IPv6 assignment and end-to-end dual-stack behavior should still be verified for the exact resource you are deploying. Before adding a public AAAA record, check the current Raff dashboard or documentation for:

• whether the VM or load balancer has a public IPv6 address
• how that address is routed
• whether platform firewall rules cover IPv6
• whether the selected private network uses IPv4, IPv6, or both

Use Linux VMs for the application layer and Private Cloud Networks to keep internal service traffic away from unnecessary public exposure.

The live pricing page should be used for current infrastructure costs rather than embedding plan prices in a networking guide.

Common mistakes

Publishing AAAA before testing the route

A DNS record can send real users to an incomplete path.

Protecting only IPv4

IPv6 exposure requires its own firewall review.

Assuming the application listens on both families

Confirm the actual socket configuration.

Hardcoding IPv4 addresses

Use DNS names when possible and make storage formats IPv6-safe.

Treating private addressing as full isolation

Private networks and firewall policy solve different parts of the security model.

Monitoring only one path

A service can be healthy over IPv4 and unavailable over IPv6, or the reverse.

Conclusion

IPv4, IPv6, and dual-stack are operational choices that affect much more than address format.

IPv4 remains the simplest compatibility baseline. IPv6 provides long-term address flexibility. Dual-stack is often the safest public migration model because it preserves IPv4 while introducing IPv6 gradually.

The success of dual-stack depends on the complete path: address assignment, routing, DNS, firewall rules, application binding, TLS, and monitoring. Test each family separately and publish only routes that are ready to serve users.

Sources

• Cloud-init documentation
• RFC 8305: Happy Eyeballs Version 2
• Raff Private Cloud Networks