Are there performance differences between ping and ping6?

Question

I've noticed ping6 command was significantly slower than ping on MacOS 10.12.

Using ping6 command:

  ❯ ping6 localhost
  PING6(56=40+8+8 bytes) ::1 --> ::1
  16 bytes from ::1, icmp_seq=0 hlim=64 time=0.088 ms
  16 bytes from ::1, icmp_seq=1 hlim=64 time=0.092 ms
  16 bytes from ::1, icmp_seq=2 hlim=64 time=0.137 ms
  16 bytes from ::1, icmp_seq=3 hlim=64 time=0.117 ms
  16 bytes from ::1, icmp_seq=4 hlim=64 time=0.116 ms
  16 bytes from ::1, icmp_seq=5 hlim=64 time=0.112 ms
  16 bytes from ::1, icmp_seq=6 hlim=64 time=0.149 ms
  16 bytes from ::1, icmp_seq=7 hlim=64 time=0.116 ms
  16 bytes from ::1, icmp_seq=8 hlim=64 time=0.119 ms
  16 bytes from ::1, icmp_seq=9 hlim=64 time=0.125 ms
  ^C
  --- localhost ping6 statistics ---
  10 packets transmitted, 10 packets received, 0.0% packet loss
  round-trip min/avg/max/std-dev = 0.088/0.117/0.149/0.017 ms

Using regular ping command:

  ❯ ping localhost
  PING localhost (127.0.0.1): 56 data bytes
  64 bytes from 127.0.0.1: icmp_seq=0 ttl=64 time=0.048 ms
  64 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=0.040 ms
  64 bytes from 127.0.0.1: icmp_seq=2 ttl=64 time=0.070 ms
  64 bytes from 127.0.0.1: icmp_seq=3 ttl=64 time=0.071 ms
  64 bytes from 127.0.0.1: icmp_seq=4 ttl=64 time=0.077 ms
  64 bytes from 127.0.0.1: icmp_seq=5 ttl=64 time=0.083 ms
  64 bytes from 127.0.0.1: icmp_seq=6 ttl=64 time=0.109 ms
  64 bytes from 127.0.0.1: icmp_seq=7 ttl=64 time=0.076 ms
  64 bytes from 127.0.0.1: icmp_seq=8 ttl=64 time=0.040 ms
  64 bytes from 127.0.0.1: icmp_seq=9 ttl=64 time=0.068 ms
  ^C
  --- localhost ping statistics ---
  10 packets transmitted, 10 packets received, 0.0% packet loss
  round-trip min/avg/max/stddev = 0.040/0.068/0.109/0.020 ms

I can't think of why using IPv6 would be slower than IPv4, so is there any reason why using ping6 would be slower than using ping?

Updated

I've removed the example of pinging a remote hostname. It was not relevant since I can't be sure the machines that are reached are the same in both tests It could also lead to answers not concerning my primary question.

Answer 1

The implementation of ping and ping6 binaries are not quite the same.

Also, neither reports the tcpdump measured time.

Here's one example, though I did several for myself. Here's the tcpdump command I used:

tcpdump -i lo0 -t 5 -nqK

 00:00:00.000000 IP6 ::1 > ::1: ICMP6, echo request, seq 0, length 16
 00:00:00.000033 IP6 ::1 > ::1: ICMP6, echo reply, seq 0, length 16

This shows a timestamp delta of 0.033 ms between the first IPV6 packet and the reply.

ping6 however, reported the round-trip time as 0.109 ms.

 00:00:00.000000 IP 127.0.0.1 > 127.0.0.1: ICMP echo request, id 17569, seq 0, length 64
 00:00:00.000034 IP 127.0.0.1 > 127.0.0.1: ICMP echo reply, id 17569, seq 0, length 64

This tcpdump shows an actual RTT of 0.034 ms, but ping reports a RTT of 0.080 ms.

ping and ping6 are two different binaries; IPv6 is, by nature of its longer addressing, going to take a bit more CPU cycles to deal with, even if they were identical binaries in every other way (they're not).

However, the packet capture suggests that the network stacks of my Mac mini are comparatively fast; it's the ping and ping6 round trip time calculations that are off, ping6 more so than what I expect to be much simpler ping.

Answer 2

You are pinging 2 different servers try pinging these 2 google servers for comparison sake, as you can see IPv6 is much much faster when it is properly supported.

IPv6: 2001:4860:4860::8888

IPv4: 8.8.8.8

64 bytes from 2001:4860:4860::8888: icmp_seq=1 ttl=61 time=3.71 ms
64 bytes from 2001:4860:4860::8888: icmp_seq=2 ttl=61 time=1.67 ms
64 bytes from 2001:4860:4860::8888: icmp_seq=3 ttl=61 time=1.62 ms
64 bytes from 2001:4860:4860::8888: icmp_seq=4 ttl=61 time=3.34 ms
64 bytes from 2001:4860:4860::8888: icmp_seq=5 ttl=61 time=2.63 ms

Reply from 8.8.8.8: bytes=32 time=23ms TTL=59
Reply from 8.8.8.8: bytes=32 time=24ms TTL=59
Reply from 8.8.8.8: bytes=32 time=8ms TTL=59
Reply from 8.8.8.8: bytes=32 time=12ms TTL=59

Answer 3

There's really no good reason for IPv6, as a protocol, to be significantly faster or slower than IPv4. I guess IPv6 might be ever-so-slightly slower due to its longer addresses causing slightly more overhead, but that's about it.

Whether IPv4 or IPv6 is faster on a given traffic flow is almost always because of differences in the the network topology/path, and the relative quality of the IPv4 and IPv6 implementations on the endpoints and middleboxes.

Several years ago, IPv6 was often slower than IPv4 because the IPv4-handling path in most routers was often hardware-optimized ("fast path") whereas the IPv6-handling path was all done in software.

Currently, IPv6 is often faster than IPv4 because it doesn't go through any NATs, whereas IPv4 often has to go through NAT gateways which can be overloaded. But there are still network paths today where IPv4 will be faster than IPv6. It really depends quite a bit on network topology and the quality of the harware and software of the endpoints and middleboxes.

Beware that when you ask DNS for a given hostname's IPv4 and IPv6 addresses, there's no guarantee that all of those addresses go to the same physical box. This is especially true when dealing with big name websites that use CDNs. And even if they do go to the same physical box, there's no guarantee that IPv4 and IPv6 will use the same route across the network. I fact, it's quite common for there to be NAT gateways in the IPv4 path but not the IPv6 path.

The case you documented of macOS loopback pings being so different in the IPv4 vs IPv6 case is interesting. It seems like those two cases should be a lot closer in speed than what you're seeing.