Running IPv4 and IPv6 on the same host is the default on every modern Linux distribution. The right pattern: prefer IPv6 for outbound when available, fall back to IPv4; listen on both for inbound.
Table of contents
- Why run both
- The default behavior
- The outbound pattern
- The inbound pattern
- What usually breaks
- The address planning
- The transition mechanisms
- FAQ
Why run both
Three reasons:
- IPv4-only networks still exist. The team that turns off IPv4 loses connectivity to the parts of the internet that haven’t deployed IPv6 yet.
- IPv6-only networks are growing. Mobile carriers in many countries default to IPv6. The team that turns off IPv6 loses connectivity to those users.
- Some apps are IPv6-only. The team that runs a service on IPv6-only gets simpler networking and more address space.
The default is dual-stack. The team that has a reason to disable one protocol should have a specific reason, not “I don’t understand the other one”.
The default behavior
On a fresh Linux install:
- IPv6 is enabled, link-local addresses on every interface.
- SLAAC or DHCPv6 assigns global IPv6 addresses when the network has a router.
- IPv4 is enabled via DHCP.
Most apps prefer IPv6 (getaddrinfo returns AAAA records first, then A). The team that wants to change this priority sets gai.conf (the label 2002::/16 rule, or the more modern precedence ::ffff:0:0/96 rule).
The outbound pattern
The right pattern for outbound connections:
- App calls
getaddrinfo("example.com"). - Resolver returns AAAA record (IPv6) if available.
- App tries IPv6 first.
- If IPv6 fails, app falls back to A record (IPv4).
This is Happy Eyeballs in the kernel; most apps implement it transparently. The team that wants to verify: curl -v https://example.com shows the resolved address.
The inbound pattern
The right pattern for a server:
- Listen on
0.0.0.0(IPv4 all interfaces) and::(IPv6 all interfaces). - Most servers (nginx, postgres, redis) support this out of the box.
- Firewall opens both protocols on the right port.
The team that listens on only one protocol misses the clients on the other. The team that listens on 127.0.0.1 only is fine for a localhost-only service.
What usually breaks
The five pitfalls:
- DNS AAAA records are wrong. The team’s DNS has a typo in the AAAA record; clients fail to connect over IPv6 and fall back to IPv4 slowly.
- Firewall blocks IPv6. The team opened the port on IPv4 but forgot IPv6; the service is unreachable over IPv6.
- MTU mismatch. The IPv6 path has a smaller MTU than the IPv4 path; large packets fragment.
- Happy Eyeballs disabled. The app does not fall back from IPv6 to IPv4; IPv6-only hosts can’t reach the service.
::not bound. The team bound the service to0.0.0.0only; IPv6 clients getconnection refused.
The address planning
The right way to plan an IPv6 deployment:
- Provider-independent addresses. Get an IPv6 allocation from your provider (or from ARIN/RIPE/APNIC for a portable block). Use this for services that need stable addresses.
- Provider-allocated addresses. Get an IPv6 prefix from your hosting provider. Use this for internal infrastructure; addresses may change if you switch providers.
- ULA (Unique Local Addresses).
fc00::/7range, the IPv6 equivalent of RFC 1918 private addresses. Use for internal-only services.
The team that has a clear address plan has a smooth IPv6 rollout. The team that winges it has address conflicts and routing issues.
The transition mechanisms
The four ways to run IPv4 and IPv6 together:
- Dual-stack. Both protocols run on every host. Most common approach; simplest to reason about.
- Tunneled (6in4, 6to4, Teredo). IPv6 packets encapsulated in IPv4. Used when IPv6 native isn’t available. Latency penalty; rarely needed today.
- NAT64/DNS64. IPv6-only hosts reach IPv4-only servers via a translator. Useful for mobile carriers and IoT.
- 464XLAT. Combines NAT64 and translation on the client. Used by mobile carriers for IPv6-only phones.
The team that uses dual-stack is fine. The team that uses tunneling has latency and MTU issues. The team that uses NAT64 has a working IPv6-only deployment.
FAQ
Should I disable IPv4?
Only on a network that you control entirely and where all clients are IPv6-capable. The team that disables IPv4 on a public-facing service breaks connectivity to IPv4-only clients.
Should I disable IPv6?
Only on a network where you have a specific compatibility reason. The team that disables IPv6 because “I don’t understand it” is breaking a feature, not fixing a bug.
How do I check if IPv6 is working?
curl -6 https://example.com and curl -4 https://example.com. The team that wants a test server: https://ipv6.google.com (Google’s IPv6 endpoint).
What’s Happy Eyeballs?
RFC 6555. The algorithm that tries IPv6 and IPv4 in parallel when both are available and uses whichever connects first. Most modern operating systems implement it in the kernel.
Should I disable IPv4 on internal services?
Not unless you have a specific reason. The team that disables IPv4 on internal services breaks older clients. The team that supports both has the most flexibility.
How do I find duplicate IPv6 addresses?
ip -6 neighbor show shows the neighbor cache. Duplicate addresses show up as multiple entries for the same address. The fix: find the host that’s using a duplicate address and reconfigure.
What’s the IPv6 equivalent of 127.0.0.1?
::1. Same loopback concept, different format.
If you are sizing the infrastructure for the kind of project this post covers, the RunxBuild hosting calculator is the right place to model the line items. The compute, the memory, the storage, the bandwidth, the database - each one is a separate number, and the team’s mental model for the platform is the sum of those numbers. The RunxBuild dashboard is where the team sees the actual usage in one place.
Useful related references: