nanog mailing list archives

RE: IPv6 Performance (was Re: IPv4 Pricing)


From: Vasilenko Eduard via NANOG <nanog () lists nanog org>
Date: Thu, 4 Dec 2025 06:22:19 +0000

Hi Lee,
1.
Yes, indeed, https://stats.labs.apnic.net/v6perf shows -6.1ms globally.
Highly probably, Geoff did everything right, we could trust the numbers.
But sorry, there is no explanation why? At least, I have never seen anything that could be called "prove".
Your speculation is the same reliable as mine. Actually, mine (about new networks -> high quality) looks more probable 
for me.
Oceania, Africa numbers (+2.62ms, +7.32ms) looks like indirect prove to this speculation - they have less money to 
construct high quality networks.

2.
RTT does not matter. Not at all. Because it is not visible for the end user directly and it has negligible influence 
for the good Congestion Control (like BBR).
User cares only about the FCT (flow completion time).
FCT is dependent on (in priority): 1) bottleneck bandwidth, 2) packet loss, 3) congestion control convergence, 4) RTT 
(but only if congestion control is bad), and a few other things.
Subtracting 2.6(6)% of the goodput (because of bigger overhead) make IPv6 fundamentally slower (for the all other 
things equal). Almost any session (except ssh) would be delayed.
IMHO: by 1.6% it is justified, IP address space should be expanded. 1.0(6)% is lost (4B+4B in addresses used not for 
addressing) just because of consensus process in the IETF.
But even if something is 1) fully justified or 2) the lost is small (1.0(6)%?): if it slower then it is not faster.

Ed/
-----Original Message-----
From: Lee Howard <lee () asgard org>
Sent: Wednesday, December 3, 2025 23:15
To: Vasilenko Eduard <vasilenko.eduard () huawei com>; North American
Network Operators Group <nanog () lists nanog org>
Subject: Re: IPv6 Performance (was Re: IPv4 Pricing)

Show me literally any data to support your hypothesis. I showed my work, with
measurements and analysis.

For example, you could use the APNIC Labs data I showed to compare newer
and older networks. We might then ask how old those networks are. Then for
anyone concerned that IPv6 would be slower on their network, they could
compare their network's age.

Without that data, and with all of the data I have see, I have to conclude that
you are simply wrong about IPv6 being slower.

Lee

On 12/3/2025 2:20 AM, Vasilenko Eduard wrote:
My hypothesis, supported but unproven
My hypothesis, supported but unproven: IPv6 is activated on new networks.
New networks have a bigger capacity and better hardware/software.
Moreover, new networks have been designed with the bigger previous
experience. It is not always the case, but typically, new things are better than
the previous generation.
Ed/
-----Original Message-----
From: Lee Howard via NANOG <nanog () lists nanog org>
Sent: Tuesday, December 2, 2025 20:28
To: nanog () lists nanog org
Cc: Lee Howard <lee () asgard org>
Subject: Re: IPv6 Performance (was Re: IPv4 Pricing)

Before you call people silly, you might want to collect some data.

You would think IPv6 headers would add processing time, but that
turns out not to be the case. Yes, they may sometimes be routed along
different paths, but I have seen IPv6 have fewer hops and lower
latency as often as I've seen
IPv4 be faster. When I was at a large network, I published these
results, measuring from many points in the network to many common
destinations, and there was no predictable difference.

This is true for CGN, firewall, load balancer, router, translator, or
any other hardware. The *only* exception is some limited release
devices that kicked
IPv6 forwarding to the software plane; I would argue that that is not
IPv6 support. If anyone else has contrary experience or data, please
share. To be fair, such devices also do not add measurable latency in
performing NAT44.

Many networks have reported that IPv6 has lower latency, in fact.[1]
In North America, IPv6 has a 2ms advantage over IPv4.[2]

This is *as measured* not based on theory.

My hypothesis, supported but unproven, is that when a device uses or
prefers
IPv6 (such as on an IPv6-only network with translation) and tries to
reach an
IPv4 destination, the device uses software CLAT to convert IPv4 to
IPv6 in the device before forwarding. This would be the case, e.g.,
for an Android device on an IPv6-only network like T-Mobile, maybe
Charter.  [3] I haven't seen the new Windows CLAT, but it wouldn't be
surprising.

It is fair to say that in general or overall, IPv6 has a slight
performance advantage over IPv6. That may not hold true for all
permutations of endpoints or devices, so your individual experience may
vary.

Lee


[1] e.g.,
https://www.internetsociety.org/blog/2015/04/facebook-news-feeds-load
-20-
40-faster-over-ipv6/


[2] https://stats.labs.apnic.net/v6perf/XQ

[3] Measurements and explanation at
https://www.arin.net/blog/2019/06/25/why-is-ipv6-faster/


On 12/2/2025 2:09 AM, Vasilenko Eduard via NANOG wrote:
Fundamentally, IPv6 should be slower because of the bigger
headers/overhead.
But it could be faster because CG-NAT detour (if CG-NAT is not on
the
shortest path).
IPv4 and IPv6 could both be faster/slower because of non-congruent
peering
topology.
Actually, the claim that IPv6 is faster is pretty silly.
Ed/
-----Original Message-----
From: Marco Moock via NANOG <nanog () lists nanog org>
Sent: Tuesday, December 2, 2025 07:42
To: nanog () lists nanog org
Cc: Marco Moock <mm () dorfdsl de>
Subject: Re: IPv6 Performance (was Re: IPv4 Pricing)

On 01.12.2025 16:44 Bryan Fields via NANOG <nanog () lists nanog org>
wrote:

At least once or twice a month I'm downloading something and will
find the IPv4 to transfer significantly faster.  Case in point, I
downloaded the proxmox iso yesterday to a colo server with 50g
uplinks.  It loafed at 2.4 mbytes/s using default wget, which of
course preferred ipv6.  Adding -4 to wget made that shoot up to 80
mbytes/s.
Have you checked packet loss and latency?

Maybe that is caused by different routes due to peering.

--
kind regards
Marco

Send spam to abfall1764603853 () stinkedores dorfdsl de
_______________________________________________
NANOG mailing list

https://lists.nanog.org/archives/list/nanog () lists nanog org/message/E
BHOWL
WPDOYOV2ATJPYBAA2CLI6SMIEE/
_______________________________________________
NANOG mailing list
https://lists.nanog.org/archives/list/nanog () lists nanog org/message/I
L5AHCA
XCZRJACSQMCFETQEY4GDVX57L/
_______________________________________________
NANOG mailing list 
https://lists.nanog.org/archives/list/nanog () lists nanog org/message/ZMGZWFC3UOCEDDWA42SP7LJN4RPXVL23/

Current thread: