Support IPv6 in the ping plugin

[kostasb]

Feature Request: Support IPv6 ping by adding a configuration option in the plugin to switch to using the ping6 tool instead of ping.

IPv6 ICMP is not supported by the ping tool.

ping6 ipv6.google.com
PING6(56=40+8+8 bytes) 2a02:214d:8225:4000:b932:d1e7:533d:be94 --> 2a00:1450:4016:804::200e
16 bytes from 2a00:1450:4016:804::200e, icmp_seq=0 hlim=56 time=43.345 ms

Reference:

The ping6 utility is intentionally separate from ping.

     There have been many discussions on why we separate ping6 and ping.
     Some people argued that it would be more convenient to uniform the ping
     command for both IPv4 and IPv6.  The followings are an answer to the
     request.

     From a developer's point of view: since the underling raw sockets API is
     totally different between IPv4 and IPv6, we would end up having two types
     of code base.  There would actually be less benefit to uniform the two
     commands into a single command from the developer's standpoint.

     From an operator's point of view: unlike ordinary network applications
     like remote login tools, we are usually aware of address family when
     using network management tools.  We do not just want to know the
     reachability to the host, but want to know the reachability to the host
     via a particular network protocol such as IPv6.  Thus, even if we had a
     unified ping command for both IPv4 and IPv6, we would usually type a
     -6 or -4 option (or something like those) to specify the particular
     address family.  This essentially means that we have two different
     commands.

source

[danielnelson]

We need to gather ping6 examples for Linux, BSD, Windows. Also interesting, on Debian ping6 is a symlink to ping which has a -6 option.

[MarkMartinec]

From an operator's point of view: unlike ordinary network applications like remote login tools, we are usually aware of address family when using network management tools. We do not just want to know the reachability to the host, but want to know the reachability to the host via a particular network protocol such as IPv6. Thus, even if we had a unified ping command for both IPv4 and IPv6, we would usually type a -6 or -4 option (or something like those) to specify the particular address family. This essentially means that we have two different commands.

That assumption is wrong, or better, it has been invalidated by pragmatic needs of users, and by time. A monitoring application or a user may not know the address family of the target address, it/he is often just interested in reachability of a target host. Even when one does indeed care about a specific address family, it is as easy as specifying a -4 or -6 option in a rare case where a target is specified as a DNS name (as opposed to an IP address) and has both an A as well as an AAAA address record.

Now consider the opposite: when a monitoring application is given a host name of a target (not its IP address). In order to determine whether to call ping or ping6, the application (or a script) has to perform a DNS lookup to collect addresses, and has to be aware of the connectivity capabilities of the monitoring host, to be able to find
an intersection and choose which protocol to use. This complication is way above competences of some ad-hoc monitoring/testing script, and even beyond many dedicated monitoring applications, which just hand the burden of choice over to a user, washing hands and murmuring something about internal coding complications and different ICMP protocol numbers.

Even though icmp and icmp6 protocols use a different protocol number and differ in details, their purpose and functionality is pretty much the same (with icmp6 providing more functions, but keeping basic functions very close to icmp).

To summarize the choices of a protocol to use:

• when a target is given as an IP address (not a DNS name), this uniquely determines the protocol;

• when a target is given as a DNS name, and a DNS lookup returns all addresses of the same address family, this again uniquely determines the protocol to use;

• when a source host only has connectivity capabilities of a single address family, that again uniquely determines the protocol to use even when the target DNS name returns addresses of both families;

• in the remaining case (source and target in both address families), a user may only care about reachability of the target, so choosing one or the other may not matter;

• in the last remaining case, one can force the choice by explicitly specifying options -4 or -6, or specify the target with an IP address instead of a name;

The world has moved on. Producers of network equipment have chosen a pragmatic approach years ago by providing a unified ping (and traceroute) in their gear, with options to override the automatic choice. This holds true for players like Cisco, Extreme Networks, MikroTik RouterOS, I believe also Juniper, and more.

Similarly, Microsoft did the same, the ping command in Windows 7/8/10 is a unified ping, with optional protocol override. (also the unified traceroute)

Luckily Linux has followed the lead, so in CentOS 7 / RHEL 7, Fedora 25 (probably in 24 as well), there is a unified ping with options -4 and -6, and for compatibility the ping6 is a link to it.

In OpenBSD 6.1 the ping and ping6 are the same file (hard link), although unfortunately it does not automatically chose the protocol by itself. Similarly in Ubuntu 16.10 the ping4 and ping6 are soft links to the same program.

Sorry about the rambling, I had to let it out. Now to the topic of options compatibility. I tried a couple of platforms, considering that the ping plugin to telegraf only cares about options -I, -i, -c, -s, -n, and -W, so here are my findings.

I tried: FreeBSD 11 (and 10, should be the same as MacOS), NetBSD 7.1, OpenBSD 6.1 (devel), Debian 8, Ubuntu 16.10, Fedora 25, CentOS 7, and Windows 10.

Interface to send ping from:

• option -I is used in both ping and ping6 on these platforms (except Windows, which offers no choice of an interface). Although its value differs, as it may be an interface name or a source IP address.

Interval at which to ping:

• option -i is used in both ping and ping6 on all these platforms, time is in seconds;

Number of pings to send:

• option -c is used in both ping and ping6 on these platforms except for Windows, which uses option -n for this purpose;

Packet size (in bytes):

• option -s is used in both ping and ping6 on all these platforms;

Numeric only:

• option -n is used in both ping and ping6 on these platforms except for Windows, which has no such option (and -n means something else)

The troublesome option is a ping timeout, which varies wildly:

• FreeBSD, MacOS: ping -W, time in milliseconds
• FreeBSD, MacOS: ping6 -X, time in seconds (-W means something else)
• Windows: -w, time in milliseconds
• Fedora, CentOS, Ubuntu, Debian: -W, time in seconds
• CentOS 7 additionally has: -w deadline [s]
• OpenBSD 6.1: -w maxwait in seconds
• NetBSD 7.1 ping: -w timeout in seconds
• NetBSD 7.1 ping6: no timeout option, (-w means something else)

As for the IPv4 vs. IPv6 override options on platforms which provide a unified ping:

Cisco IOS:

• ping ip
• ping ipv6
• (IPv6 preferred)

Summit ExtremeXOS:

• ping ipv4
• ping ipv6
• (IPv4 preferred)

MikroTik RouterOS:

• no override options, one has to use a numeric address to be explicit
• (IPv4 preferred)

Windows 10:

• -4
• -6
• (IPv6 preferred)

Fedora 25:

• -4
• -6
• (IPv6 preferred)

CentOS 7:

• -4
• -6
• (IPv4 preferred)

[danielnelson]

Obviously this is tricky since ping is many different programs. I think we could get closer if we allow the path to ping to be configured as well as letting the user pass a list of args. It would be similar to the proposal in #2505