Is IPv6 faster than IPv4? The honest answer: usually no significant difference, sometimes slightly faster (no NAT, simpler header parsing), occasionally slightly slower (less mature path, MTU discovery issues, or specific implementation bugs). The team that benchmarks a specific path on a specific workload gets the only meaningful answer. Most teams find IPv4 and IPv6 within 5-10% of each other on a well-provisioned network.
Table of contents
- Why IPv6 could be faster (in theory)
- Why IPv6 could be slower (in practice)
- How to actually measure
- When IPv6 is meaningfully faster
- When IPv6 is meaningfully slower
- Happy Eyeballs (RFC 6555) - the right way to dual-stack
- How this fits the rest of the stack
- FAQ
Why IPv6 could be faster (in theory)
-
No NAT - IPv4 with carrier-grade NAT adds 1-5 ms per packet and complicates connection tracking. IPv6 has 1:1 addressing, so the path is shorter.
-
Simpler header - IPv6’s fixed 40-byte header is easier to parse in hardware. The team that builds packet-processing ASICs and NICs finds IPv6 slightly faster to handle.
-
No fragmentation in routers - IPv6 routers do not fragment. The host does Path MTU Discovery once and sends packets that fit. Less work in transit, lower jitter.
-
Multicast instead of broadcast - some IPv4 networks have broadcast storms that IPv6 avoids. The team that benchmarks on a busy IPv4 network sees less noise on IPv6.
Why IPv6 could be slower (in practice)
-
Less mature path - some networks and ISPs have less optimized IPv6 paths than their IPv4 paths. The team that has an ISP that is still rolling out IPv6 sees higher latency and packet loss.
-
MTU issues - IPv6 requires Path MTU Discovery. If a router in the path silently drops packets larger than its MTU, the IPv6 stack takes longer to discover the right size. The team that sees “connection works for small requests, fails for large” on IPv6 has an MTU issue.
-
Application bugs - some applications have IPv6-specific bugs (wrong address family used, hardcoded IPv4 localhost, etc.). The team that has an app that works on IPv4 but not IPv6 is hitting an app bug, not a protocol issue.
-
Dual-stack overhead - some systems try IPv6 first, then fall back to IPv4 after a timeout. If the IPv6 path is slow, the total request time is the IPv6 timeout + the IPv4 request, not just the IPv4 request.
How to actually measure
Same source, same destination, same time of day, same payload size. The team that benchmarks properly:
# IPv4
ping -c 100 destination.example.com
# IPv6
ping6 -c 100 destination.example.com
# or
ping -6 -c 100 destination.example.com
Compare average latency, jitter (standard deviation), and packet loss. The team that wants the full picture uses mtr (My Traceroute) on both:
mtr -4 destination.example.com
mtr -6 destination.example.com
mtr shows per-hop latency and loss, which reveals where one path differs from the other.
When IPv6 is meaningfully faster
The team that consistently sees IPv6 faster is usually on a path where:
-
The ISP uses carrier-grade NAT for IPv4 (1-5 ms NAT overhead per packet).
-
The destination is on a CDN or cloud provider that has separate IPv4 and IPv6 infrastructure, and the IPv6 path is shorter or less congested.
-
The application is connection-heavy (many small requests), and the connection setup is faster without NAT tracking.
A 10-30% latency improvement is common in these cases. The team that has a real-time workload (gaming, video, financial trading) cares about this delta; the team that has a web API with one request per second does not.
When IPv6 is meaningfully slower
The team that sees IPv6 consistently slower is usually on:
-
A residential ISP that has poor IPv6 peering (IPv4 traffic goes through Tier-1 carriers, IPv6 goes through the ISP’s own limited peering).
-
A path with broken Path MTU Discovery (some routers do not send ICMPv6 Packet Too Big correctly).
-
An application that has IPv6 code paths with bugs (usually the connection-setup code, not the steady-state).
The fix for the ISP case: complain to the ISP, or use IPv4 with a happy-eyeballs approach (try both, use whichever works). The fix for the MTU case: enable net.ipv6.ip_no_pmtu_disc=1 (force a smaller MTU) or fix the broken router.
Happy Eyeballs (RFC 6555) - the right way to dual-stack
Happy Eyeballs is the algorithm most modern systems use: try IPv6 and IPv4 in parallel, use whichever connects first. The team that has this enabled has the best of both worlds.
Browsers do this. Most application frameworks do this. curl --happy-eyeballs (or just curl with dual-stack) does this.
The team that builds a new client application should use the system’s getaddrinfo() and let the OS do Happy Eyeballs. The team that hand-rolls IPv4-then-IPv6 or IPv6-then-IPv4 sequential connection attempts loses the benefit.
FAQ
Is IPv6 faster than IPv4 on a specific ISP?
It depends. Some ISPs have better IPv6 paths than IPv4; some have worse. The team that benchmarks on their own ISP gets the only correct answer.
Does IPv6 reduce latency for gaming?
Sometimes - 5-30 ms is common when the IPv4 path uses carrier-grade NAT and the IPv6 path does not. The team that games on a server with both stacks enabled has the lower latency automatically with Happy Eyeballs.
Why is my IPv6 connection slower than IPv4?
Most common causes: ISP peering for IPv6 is less optimized, Path MTU Discovery is broken, or the application has a bug in its IPv6 code path. The team that uses mtr to compare per-hop latency finds the bottleneck.
Should I disable IPv6 if it is slower?
Only if the speed difference is significant for your workload. Most teams find the difference is in the noise (<10%) and the benefits of dual-stack (better reachability, future-proofing) outweigh the cost. The team that runs a latency-critical workload (real-time gaming, voice, video) and sees a real difference disables IPv6 on the affected systems only.
Does Happy Eyeballs work in browsers?
Yes - all major browsers implement it. The user opens a URL, the browser tries IPv6 and IPv4 in parallel, uses whichever connects first. The user never sees the dual-stack decision.
How this fits the rest of the stack
For a sense of what the full project costs before it commits, the RunxBuild hosting calculator shows the line items together. The API, the database, the storage, the worker, the bandwidth - each one is a separate number, and the team’s mental model for the platform is the sum of those numbers.
Useful related references: