ping6 and other tool6 awkwardness

[Chuck Anderson]

On Wed, May 13, 2015 at 01:10:05PM -0700, J.C. Cleaver wrote:
> On Tue, May 12, 2015 1:41 am, Richard W.M. Jones wrote:
> > On Tue, May 12, 2015 at 10:34:28AM +0200, Nikos Mavrogiannopoulos wrote:
> >> On Tue, 2015-05-12 at 09:04 +0100, Richard W.M. Jones wrote:
> >> > > While working for an updated ipcalc to support ipv6 transparently, I
> >> > > figured we have more tools which are not IPv6-ready and awkwardly
> >> > > provide an additional tool with a -6 suffix, supposedly for separate
> >> > > IPv6 support. That looks like a relic of the past, we still drag.
> >> IPv6
> >> > > support should be transparent in programs (fortunately we don't have
> >> > > ssh6). Any objection to fill bugs to merge the following tools with
> >> > > their ipv4 equivalent?
> >> > >
> >> > > ping6, geoiplookup6, tracepath6, traceroute6
> >> >
> >> > While I agree with your assessment of the separate tools, I think
> >> > you're better off filing bugs with the upstream projects.
> >>
> >> I'm interested in what fedora ships rather than the upstream project per
> >> se.
> >
> > Fedora ships whatever upstream ships.  Big changes like integrating
> > separate programs together should be made upstream.
> >
> > https://fedoraproject.org/wiki/Staying_close_to_upstream_projects
> >
> >> The fedora maintainer may chose to switch to another upstream
> >> project if that is required.
> >
> > Are there other such projects that have all the features of current
> > ping/traceroute/etc but integrate the tools together?
> >
> > Rich.
> >
> 
> 
> Probably worth it to add fping/fping6 to the list as well:
> https://github.com/schweikert/fping

As Fedora fping maintainer, I can't do anything with this.  It needs
to be filed upstream.

I see a few reasons why network testing tools like ping, traceroute,
fping, etc. may still be using separate binaries for IPv6.

One is that when you are testing network functionality, you often want
to test IPv4 or IPv6 specifically.  These tools aren't really end-user
applications like ssh, where you don't care what protocol it uses to
connect because the protocol is just a means to an end.  With the
network testing tools, you often DO care.

Two is that the network testing tools often need to do
protocol-specific low-level things, like open raw sockets or build
packets manually rather than relying on the OS TCP/IP stack to do it.

Three is that these tools were often ported from IPv4 and don't
support integrated functionality (due to #2).  They can be compiled
for either IPv4 or IPv6, but not both at the same time.  For example,
the fping RPM used to build the software twice--once for IPv4 and once
for IPv6--and then package up the results together.  This changed with
newer fping versions, however.

I don't think pushing Fedora maintainers on this by filing bugs
downstream is going to change things.  It is the upstream software
that needs enhancement, so the bugs should be filed upstream.  Also,
suggesting alternate upstream projects that have the integrated
IPv4/IPv6 functionality is fine, but they may not be drop-in
replacements for the existing tools.  In that case the existing tools
should stay and the new ones can be added to the distro separately if
desired.  You can't exactly stop shipping a "ping" command and replace
it with "gnip" just because the latter supports IPv4+IPv6 with a
single command.  Add it sure, but not replace.