Bug 617934 - 'ping' should support IPv6
'ping' should support IPv6
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: iputils (Show other bugs)
rawhide
All Linux
low Severity low
: ---
: ---
Assigned To: Jan Synacek
Fedora Extras Quality Assurance
: Reopened
Depends On:
Blocks: dualstack 1220694
  Show dependency treegraph
 
Reported: 2010-07-25 00:56 EDT by Peter
Modified: 2016-01-22 02:37 EST (History)
9 users (show)

See Also:
Fixed In Version: iputils-20150815-1.fc24
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2015-09-24 08:12:08 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Peter 2010-07-25 00:56:07 EDT
Description of problem:

The current system of using different software (ping vs ping6) for different versions of the IP stack is broken.  As the IPv6 transition moves ahead its unreasonable to expect users to know in advance the IP version of a peer referenced using a DNS name.

ping should work like traceroute supporting both protocol versions by default.

Version-Release number of selected component (if applicable):
ping utility, iputils-sss20071127

How reproducible:
Always

Steps to Reproduce:
1. ping ipv6.google.com

  
Actual results:
Unknown host

Expected results:
PING ipv6.google.com(pv-in-x6a.1e100.net) 56 data bytes
64 bytes from pv-in-x6a.1e100.net: icmp_seq=1 ttl=50 time=149 ms
64 bytes from pv-in-x6a.1e100.net: icmp_seq=2 ttl=50 time=150 ms
ò^C
--- ipv6.google.com ping statistics ---

Additional info:
Comment 1 Jiri Skala 2010-08-16 03:46:37 EDT
Hi,
I see proposed enhancement quite logical. On the other hand current state is deep-seated.

I've asked upstream about opinion/planing a couple weeks ago (currently no response). I'll decide next step after receiving any response from upstream.

Jiri
Comment 2 Jiri Skala 2010-12-16 06:10:05 EST
Non-responsive upstream. I don't want to do huge changes without upstream co-operation/adoption. Among others pinging via IPv6 is possible.
Comment 3 Pavel Šimerda (pavlix) 2013-01-07 08:48:57 EST
Reopening this bug report as part of your dualstack networking effort.

See:

https://fedoraproject.org/wiki/Features/DualstackNetworking

Comments from the tracker bug:


Michael Heimann 2013-01-03 07:43:10 EST

ping is not IPv6 compatible - instead IPv6 functions are outsourced to ping6.

How to create a bug for that and "attach" this tracker bug?


Jan Synacek 2013-01-07 05:19:13 EST

> ping is not IPv6 compatible - instead IPv6 functions are outsourced to ping6.
> 
> How to create a bug for that and "attach" this tracker bug?

There is no need for a bug because it is not one. I would just delete the line that mentions ping from the feature page.


And my answer:

> > ping is > > ping is not IPv6 compatible - instead IPv6 functions are outsourced to ping6.
> > 
> > How to create a bug for that and "attach" this tracker bug?

I would say a RFE for ping would do. It is common to use bug reports for requests for new features in Fedora.

> There is no need for a bug because it is not one.

Personal opinions are important part of our work. But this one is without justificatoin. Unless there is a special reason for a tool to be IPv4-only or IPv6-only it should be dualprotocol. And for ICMP ECHO tool, there is no such reason as this functionality is availabe for both IPv4 and IPv6.

There's a workaround to use a IPv6-only replacement when we work with IPv6. But as that one is IPv6-only, it doesn't constitute a universal replacement.

Most operating systems already have this feature which makes Fedora and other Linux distributions look backwards. That is not such a big deal, as we have bigger problems than that.

But what would really make us look foolish would be if we use various sorts of excuses and at the same time talk about defining distribution (or defining company for those who work at Red Hat).

> I would just delete the line that mentions ping from the feature page.

We could make this one optional for the feature, or we could split it out to another feature if we suspect we are unable to make it work. But I don't think it is justifiable to say that basic tools like ping can legitimately be IPv4-only.

Thanks for your feedback.not IPv6 compatible - instead IPv6 functions are outsourced to ping6.
> > 
> > How to create a bug for that and "attach" this tracker bug?

I would say a RFE for ping would do. It is common to use bug reports for requests for new features in Fedora.

> There is no need for a bug because it is not one.

Personal opinions are important part of our work. But this one is without justificatoin. Unless there is a special reason for a tool to be IPv4-only or IPv6-only it should be dualprotocol. And for ICMP ECHO tool, there is no such reason as this functionality is availabe for both IPv4 and IPv6.

There's a workaround to use a IPv6-only replacement when we work with IPv6. But as that one is IPv6-only, it doesn't constitute a universal replacement.

Most operating systems already have this feature which makes Fedora and other Linux distributions look backwards. That is not such a big deal, as we have bigger problems than that.

But what would really make us look foolish would be if we use various sorts of excuses and at the same time talk about defining distribution (or defining company for those who work at Red Hat).

> I would just delete the line that mentions ping from the feature page.

We could make this one optional for the feature, or we could split it out to another feature if we suspect we are unable to make it work. But I don't think it is justifiable to say that basic tools like ping can legitimately be IPv4-only.

Thanks for your feedback.
Comment 4 Jan Synacek 2013-01-07 09:38:01 EST
Ok, I guess I wasn't clear enough.

My original reasoning was that the fact that ping doesn't work with IPv6 addresses is not a bug, because there is no such functionality there. That's what ping6 is for.

Anyway, merging ping and ping6 makes a lot of sense. The upstream is quite responsive nowadays, so I'll look into it and perhaps start an upstream discussion.
Comment 5 Pavel Šimerda (pavlix) 2013-01-07 10:04:59 EST
(In reply to comment #4)
> My original reasoning was that the fact that ping doesn't work with IPv6
> addresses is not a bug, because there is no such functionality there.

Yes. My answer wasn't either. I confirm that it is not a bug but from the dualstack networking point of view it's lack of an important feature.

> That's what ping6 is for.

That's why the feature is not so urgent and why I'm considering moving it to a separate feature page.

> Anyway, merging ping and ping6 makes a lot of sense. The upstream is quite
> responsive nowadays, so I'll look into it and perhaps start an upstream
> discussion.

Thanks. Ping is not so complicated, so I think it warrants (a) discussion with upstream or (b) a fork. Especially the second option calls for a separate feature page and more time to finish it.
Comment 7 Pavel Šimerda (pavlix) 2013-01-07 10:15:30 EST
Forgot to add (c) a wrapper ping that would call ping4 or ping6 depending on its arguments.
Comment 8 Jan Synacek 2013-01-08 01:11:31 EST
(In reply to comment #7)
> Forgot to add (c) a wrapper ping that would call ping4 or ping6 depending on
> its arguments.

In my opinion this would a good way to go if there was a need to quickly
implement this idea. My understanding is that there is no such need, so I
suggest going the (a) way as well.
Comment 9 Pavel Šimerda (pavlix) 2013-01-08 07:43:58 EST
I moved it to a separate feature page that I'm *not* submitting for F19 unless upstream reacts quickly.

https://fedoraproject.org/wiki/Features/DualstackNetworkTestingTools

See also:

https://fedoraproject.org/wiki/Networking#Fedora_feature_pages
Comment 10 Jan Synacek 2013-01-23 06:39:38 EST
Upstream is ok with a unified ping. Some details are yet to be agreed on though.
Comment 11 Dmitry Butskoy 2013-01-23 11:10:48 EST
Jan,

At the time when I wrote the first new traceroute-2.0.x implementation in 2006 (certainly dual stack friendly :) always), I thought about rewriting of ping as well, since both utilities are from the same knowledge area.

But I've stopped myself, because ping and ping6 work fine at that time, and a chance to be included in a distro was too small (unlike in traceroute, which was very actual at that time).

Well, now the idea of uniting ping4/ping6 into one utility is considered good, by upstream as well. But when I last time looked into their code, the code was not so clean (not so good... etc.). Anyway it would be much better to rewrite the code, rather than combine the current ping and ping6 into one.

Could you please consider the situation -- whether the current ping upstream has a good motivation to provide a good (including "good code") common IPv4/IPv6 ping implementation, which will be suitable in Enterprise Linux as well? If so, it will be fine.

But if not, I feel some responsibility in this, since yes, I'm capable to re-write the ping from the scratch... With code and style similar to the current traceroute.

But certainly I should know whether it might be actually needed from me or not, to plan my time in the near future.
Comment 12 Pavel Šimerda (pavlix) 2013-01-24 20:26:03 EST
(In reply to comment #10)
> Upstream is ok with a unified ping. Some details are yet to be agreed on
> though.

That's a good news. For the beginning I don't care so much about what ping will do by default. I just want to be sure that 'ping -4' and 'ping -6' will do exactly what they should do.

(In reply to comment #11)
> Well, now the idea of uniting ping4/ping6 into one utility is considered
> good, by upstream as well. But when I last time looked into their code, the
> code was not so clean (not so good... etc.). Anyway it would be much better
> to rewrite the code, rather than combine the current ping and ping6 into one.

Then you might consider communicating with upstream and reporting the details here...

> But if not, I feel some responsibility in this, since yes, I'm capable to
> re-write the ping from the scratch... With code and style similar to the
> current traceroute.

Great.
Comment 13 Dmitry Butskoy 2013-01-25 08:05:15 EST
To comment #12:
> Then you might consider communicating with upstream and reporting the details here

I prefer some Red Hat people to do it.

Ping is "a very basic", "fundamental", "good ancient" utility etc. It should not be implemented just by an occasional people enthusiasm.
Comment 14 Fedora End Of Life 2013-04-03 16:06:37 EDT
This bug appears to have been reported against 'rawhide' during the Fedora 19 development cycle.
Changing version to '19'.

(As we did not run this process for some time, it could affect also pre-Fedora 19 development
cycle bugs. We are very sorry. It will help us with cleanup during Fedora 19 End Of Life. Thank you.)

More information and reason for this action is here:
https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora19
Comment 15 Pavel Šimerda (pavlix) 2014-04-28 11:11:01 EDT
As far as I know, ping still doesn't support IPv6 in rawhide.
Comment 16 Jan Synacek 2014-05-05 02:56:52 EDT
My priorities and duties have since shifted elsewhere, so I will not be rewriting ping.
Comment 17 Pavel Šimerda (pavlix) 2014-05-05 03:57:49 EDT
(In reply to Jan Synacek from comment #16)
> My priorities and duties have since shifted elsewhere, so I will not be
> rewriting ping.

Thanks for information.
Comment 18 David Heidelberg (okias) 2014-05-08 19:39:29 EDT
I opened bug for iputils with this topic [1].

I'll try someway import ping6 into ping and get it together. Anyway any help appreciated!

[1] https://github.com/iputils/iputils/issues/5
Comment 19 Nikos Mavrogiannopoulos 2015-05-12 10:19:14 EDT
I've put a quick hack which allows ping to use ipv6 addresses as fallback at: https://github.com/iputils/iputils/pull/16
Comment 20 Nikos Mavrogiannopoulos 2015-06-18 06:51:54 EDT
Patches are already upstream. Please consider merging them in F23.
Comment 21 Jan Synacek 2015-06-18 08:01:25 EDT
I'll wait for a release, but thanks for letting me know! I'm keeping the needinfo on myself for now.
Comment 22 Pavel Šimerda (pavlix) 2015-06-18 15:24:00 EDT
FYI

Upstream recently accepted my patches that build on top of the work by Nikos and I submitted another pull request removing ping6 entirely. For compatibility, the ping binary supports being called via a ping6 symlink to trigger IPv6 mode and for consistency a ping4 symlink can be created for the IPv4 mode.

The default mode is now full looping through all getaddrinfo() results in the given order which results in giving precedence to available protocols. If both protocols are available, getaddrinfo returns IPv6 first by default.

When there is a release, I recommend also checking that the ping6 symlink is included and creating it if it isn't. People are used to it and it is enough to trick them with ping defaulting to IPv6. Whether a ping4 symlink is useful or not remains a question.
Comment 23 Pavel Šimerda (pavlix) 2015-06-18 15:25:56 EDT
Anyone is welcome to review the new pull request:

https://github.com/iputils/iputils/pull/25
Comment 24 Pavel Šimerda (pavlix) 2015-07-14 03:29:22 EDT
Upstream now has a decent dual-stack ping command.
Comment 25 Jan Kurik 2015-07-15 11:19:08 EDT
This bug appears to have been reported against 'rawhide' during the Fedora 23 development cycle.
Changing version to '23'.

(As we did not run this process for some time, it could affect also pre-Fedora 23 development
cycle bugs. We are very sorry. It will help us with cleanup during Fedora 23 End Of Life. Thank you.)

More information and reason for this action is here:
https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora23
Comment 26 Nikos Mavrogiannopoulos 2015-08-17 04:09:11 EDT
There is a new release by upstream including the dual stack changes:
https://github.com/iputils/iputils/releases/tag/s20150815
Comment 28 Jan Synacek 2015-09-24 03:32:41 EDT
I'm sorry, I have completely missed the information about the new upstream release. New version incoming...
Comment 29 Nikos Mavrogiannopoulos 2016-01-03 12:25:27 EST
Jan do you want to submit that feature as a self contained change for Fedora 24?
Comment 30 Jan Synacek 2016-01-04 02:49:01 EST
Is that really necessary? The package is already in rawhide.
Comment 31 Nikos Mavrogiannopoulos 2016-01-05 05:37:43 EST
The self contained changes are for public announcements. Otherwise one will figure that ping supports ipv6 addresses only by accident.
Comment 32 Jan Synacek 2016-01-05 06:57:27 EST
Ok, in that case, we should probably submit the change.
Comment 33 Nikos Mavrogiannopoulos 2016-01-21 09:42:42 EST
Jan do you want me to fill the change request? I could do that, but I believe it should be you as you are the maintainer. The deadline for change requests is close.
Comment 34 Jan Synacek 2016-01-22 02:37:03 EST
(In reply to Nikos Mavrogiannopoulos from comment #33)
> Jan do you want me to fill the change request?

Yes, please.

Note You need to log in before you can comment on or make changes to this bug.