> 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 <[email protected]>
> Sent: Tuesday, December 2, 2025 20:28
> To: [email protected]
> Cc: Lee Howard <[email protected]>
> 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 <[email protected]>
> >> Sent: Tuesday, December 2, 2025 07:42
> >> To: [email protected]
> >> Cc: Marco Moock <[email protected]>
> >> Subject: Re: IPv6 Performance (was Re: IPv4 Pricing)
> >>
> >> On 01.12.2025 16:44 Bryan Fields via NANOG <[email protected]>
> >> 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 [email protected]
> > _______________________________________________
> > NANOG mailing list
> >
> https://lists.nanog.org/archives/list/[email protected]/message/EBHOWL
> WPDOYOV2ATJPYBAA2CLI6SMIEE/
> _______________________________________________
> NANOG mailing list
> https://lists.nanog.org/archives/list/[email protected]/message/IL5AHCA
> XCZRJACSQMCFETQEY4GDVX57L/
_______________________________________________
NANOG mailing list
https://lists.nanog.org/archives/list/[email protected]/message/HVIM5U4E6TTWLQCJJBGUNTDV3QKNKQSJ/
