IPv4 vs IPv6 connection quality

[CJRoss]

Has anyone noticed a big difference between the quality of their IPv4 connection and the IPv6 one?

I enabled dpinger for both my IPv4 and IPv6 gateways. The IPv4 is consistently good but the IPv6 is having nothing but problems. Consistent packet loss, high latency, and huge swings in latency.

I would have expected both stacks to be similar in performance, but I wanted to see what others experience was before I start the uphill battle in complaining to my ISP.

 

[Blue)(Fusion]

When properly setup, IPv6 and IPv4 packet loss should be 0. My IPv6 problems generally stem from dealing with the occasional IPv6 prefix change from my ISP and ensuring reliability of IPv6 on my LAN - which means I had to deploy ULA which complicated some things.

 

[CJRoss]

When properly setup, IPv6 and IPv4 packet loss should be 0. My IPv6 problems generally stem from dealing with the occasional IPv6 prefix change from my ISP and ensuring reliability of IPv6 on my LAN - which means I had to deploy ULA which complicated some things.

That was my assumption. I'm just not sure why they would be different when running across the same hardware and connection.

 

[bitbckt]

That has to be a bot… reported.

 

[kpfleming]

My ISP doesn't offer native IPv6 (at least not in a form which I can practically use), so I've been using a Hurricane Electric 'Tunnelbroker' tunnel for more than a decade.

I often see *better* performance using IPv6 to talk to random sites than I get with IPv4. Generally this happens because the traffic passes through fewer (possibly zero) NAT devices along its path.

 

[CyklonDX]

so no...

ipv4 offers better performance than ipv6. The switch cpu always prefers/prioritizes packets that are smaller, and have smaller header thus ipv4 packet will always get prioritized by switch/router. To somehow increase that performance on ipv6 they removed checksum header from ipv6. Thus ipv6 is less reliable, slower, and much bigger vs ipv4.

IPv4 vs IPv6 Performance Comparison

Our research labs test the difference between IPv4 vs IPv6 in terms of speed and performance from multiple locations around the world.

blog.sucuri.net

here's some stats, tho not sure if their testing is done right. (but it kinda shows the same thing)
// do note some networks do address translation from ipv4 to ipv6 and so on - this would reduce performance - and thats what that guy is seeing in London networks, and Tokyo ones.

 

[Blue)(Fusion]

IPv6 offers better connection quality than IPv4 due to its larger address space, improved packet routing, and built-in security features.

@MSD0010 #grabnpay.in -Networking solutions

Thanks, ChatGPT.

ipv4 offers better performance than ipv6. The switch cpu always prefers/prioritizes packets that are smaller, and have smaller header thus ipv4 packet will always get prioritized by switch/router.

Can you back up this claim? I very much doubt this to be fact.

To somehow increase that performance on ipv6 they removed checksum header from ipv6. Thus ipv6 is less reliable, slower, and much bigger vs ipv4.

Undeniably false.

Yes, IPv6 has a larger headers (until you add in QoS, VLAN tags, etc). This will affect absolute maximum data transfer rates between hosts when comparing IPv4 and IPv6 but the difference is easily acceptable in any case for the benefits. This does NOT make it slower and it certainly isn't much bigger as you imply.

The IPv6 checksums are removed because it's already happening a layer above (TCP/QUIC) and a layer below (Ethernet frames) so why do it another time? Save processing cycles. This omission of checksums absolutely does not make IPv6 less reliable than IPv4.

IPv4 vs IPv6 Performance Comparison

Our research labs test the difference between IPv4 vs IPv6 in terms of speed and performance from multiple locations around the world.

blog.sucuri.net

here's some stats, tho not sure if their testing is done right. (but it kinda shows the same thing)
// do note some networks do address translation from ipv4 to ipv6 and so on - this would reduce performance - and thats what that guy is seeing in London networks, and Tokyo ones.

IPv6 in 2023 has better support and wider spread than 2016 when the linked comparison results were published.

Watch some NANOG videos on Youtube talking about IPv6. Sure it's not perfect but getting rid of NAT alone is worth the adoption.

That was my assumption. I'm just not sure why they would be different when running across the same hardware and connection.

It might be down to DNS reverse lookups on your hosts slowing things down. I noticed once I properly setup IPv6 PTR records logging in to FreeBSD and Linux hosts was faster.

 

[BoredSysadmin]

It might be down to DNS reverse lookups on your hosts slowing things down. I noticed once I properly setup IPv6 PTR records logging in to FreeBSD and Linux hosts was faster.

 

[nikko]

I have consistently seen better latency on IPv6 compared to IPv4 behind CGNAT.

One thing I keep wondering if there is an advantage for IPv6 for clients establishing P2P connections. Given most routers implement symmetric NAT which would require the connection to be routed through a TURN server. Clients on IPv6 shouldn’t have this problem?

 

[CyklonDX]

Can you back up this claim? I very much doubt this to be fact.

That's part of CCNA/CCNP courses, as well as rational result of reading the int buffer faster (in any kind of system that processes the data).
I don't feel like looking it up. If you do it - you'll learn about that.

Undeniably false.

Sure its not required, because of how fat the packets going to be... initially in ipv6 proposed spec had checksum, but it had performance problems due to its size, as well as need on the router to recalculate checksum - significantly degrading the performance especially after few hops in the network. Instead checksum was reused from layer 2 and layer 4 protocols instead (i.e. TCP) so it was deemed unnecessary and dropped. (but has made things more difficult for udp - this was performance related change -- in short its less reliable than ipv4, and slower but in exchange you get a lot of address bit space)

 

[kpfleming]

This is some fun reading ;-)

In an HTTP or HTTPS connection, which dominate Internet traffic, the vast majority of packets are at the MTU, since the data being transferred far exceeds the MTU. Using IPv4 instead of IPv6 won't make the packets any smaller, it will just leave a few more bytes for data within the MTU envelope, and statistically speaking will sometimes avoid the need for an additional small packet at the end of the transfer.

I'm not sure where that diagram showing the packet header construction came from but it's poorly designed. The first row in the IPv4 header is 32 bits wide, but the first row in the IPv6 header is apparently 56 bits wide since it's 1.75 times as tall as the row in the IPv4 header.

 

[CyklonDX]

I wouldn't judge too much from the visual representation, it was meant to show that its bigger, especially in address space.

In an HTTP or HTTPS connection, which dominate Internet traffic, the vast majority of packets are at the MTU, since the data being transferred far exceeds the MTU. Using IPv4 instead of IPv6 won't make the packets any smaller, it will just leave a few more bytes for data within the MTU envelope, and statistically speaking will sometimes avoid the need for an additional small packet at the end of the transfer.

so, while your system may show you the bits for your visual queues; The binary format as its being modulated to be sent over medium will transform the signal based on bits. If you have lets say source address (i'll use ipv4 as example, same goes on any binary modulation)
10.0.0.1

00001010.00000000.00000000.00000001

The signal sent won't actually reflect this binary code. The signal generator will actually send out this

00001010.0.0.00000001

Some more advanced systems may utilize all kinds of tricks to get it even smaller. This is no longer physically 32bit, but 18bit that CPU will read, and interpret oh yeah this is actually 00001010.00000000.00000000.00000001 or something else... I have simplified that terribly it can get far more advanced, and there are plenty of tricks/hacks that it can be used with - since cpu on switch is quite dumb at the time of reading it.
There were many tricks that were used in past

Few decades ago where you had bigger control over your own router/modem at home from your ISP, changing subnet from /24 to bigger one lets say /16 often completely changed routing your transmission would take, and if network didn't complain / block your traffic would actually be 18 bits vs 25 bits in /24 when being transmitted, you stack few things on top of that and your packets get significantly smaller. Often leading you to networks hops you would normally not get (this in conjunction with BGP protocol - also used in some form of MITM attacks in eBGP attacks can bring down whole net as is - as you could essentially reach networks where you shouldn't be able to reach - but because CPU's are dumb and only calculate binary - one can generate packet that will in fact broadcast advertising route/s to e/BGP edge routers and bring down sites or whole net) Since then its much harder to do any of that, but to some point its still possible to do. (you shouldn't do it or even try -> alpabet friends were visiting people from defcon for years each time someone presented that.)

 

[Blue)(Fusion]

Any, despite the above FUD I've had great success with IPv6 on my home network and private VPNs to several locations.

I've converted as much as I could to IPv6. Right now my ICX6610 reports roughly 80% of traffic is IPv6. Just IPv4-only websites and IOT devices that don't support IPv6 (IP Cameras mainly) make up the IPv4 traffic. All SNMP, NFS, Samba/CIFS, HTTP/S, Syncthing, MySQL, and so on are all IPv6 on my LAN. Zero issues, performance, reliability, or otherwise.

 

[CyklonDX]

Most people, the end user, will never experience anything bad from few bits here and there - as the swtch/router cpu has plenty of time to process their packet. Who in their right mind, a common user ever stresses their switch/router on all ports at full speed at the same time. Who cares if it takes 5ns longer to read that packet; yes it has very little difference in common use (ipv4 v ipv6). The only difference happens when network is really flooded with traffic, and you are running close to the limits of that network. (ISP's networks are good examples of that - but after 1-2 hops, you would already be running at ipv4 again to gain speed in those congested waters)

 

[CJRoss]

The only IPv6 traffic happening right now is DNS queries and pings. With as bad as the connection is, I didn't bother setting anything up other than adding the IPv6 versions of my IPv4 DNS servers.

The packet loss, high latency and jitter that I'm seeing on IPv6 are all mapped via pings to my gateway through dpinger, the same way I'm monitoring my IPv4 quality.

Interestingly enough, my IPv6 connection quality has improved. It's gone from absolutely horrible to just bad. I'm not sure what caused the change and I still don't understand how there can be that much difference in pings between the two protocols over the same physical connection.

 

[TeleFragger]

I think it could be related to your ISP's network infrastructure or how they've set up routing for IPv6. Not all ISPs have put the same effort into optimizing both, unfortunately.

In my case, I found out that my issues weren't just about IPv6 but also depended on the specific type of connection I was using.

Now, I got a premium individual IPV4 from this isp proxy provider. Paying for it 3.6$/month, location Poland. The connection is always stable, and all works smoothly with it.