Re: bad default in ping

Simon Josefsson via Bug reports for the GNU Internet utilities <[email protected]> Mon, 12 May 2025 22:40:18 +0200
Newsgroups gmane.comp.gnu.inetutils.bugs
Message-ID <[email protected]>
Erik Auerswald <[email protected]> writes:

> On Mon, May 12, 2025 at 09:13:14AM +0200, Simon Josefsson via Bug reports for the GNU Internet utilities wrote:
>> Collin Funk <[email protected]> writes:
>> > [...]
>> > I wouldn't mind having 'ping' support both IPv4 and IPv6 with arguments
>> > to chose though. I think that was even but in the TODO file long ago.
>> > But I am in no rush to do so.
>> [...]
>> I disagree with Anna and think that IPv4 should still be the default,
>> although I think we should be open to revisit this in a few years if
>> IPv4 availability lowers (which I'm not seeing any signs of).
>
> The iputils ping program (the default ping on Debian GNU/Linux and derived
> distributions) combines IPv4 and IPv6 support in a single binary for
> many years now.  As commonly expected from dual-stack applications,
> it prefers IPv6 if both IPv4 and IPv6 addresses are returned by
> getaddrinfo().  Another free software dual-stack ping program would be
> fping, also preferring IPv6, also using getaddrinfo().  The dual-stack
> applications that are currently part of GNU Inetutils also prefer IPv6.
> The proprietary dual-stack ping implementation on Windows also prefers
> IPv6.  It seems to me that diverging from this common behavior in a
> dual-stack ping implementation would be rather surprising.
>
> As such I'd prefer a combined ping+ping6 implementation, i.e., a possible
> future dual-stack GNU Inetutils ping, to prefer IPv6.

Hmm, you make a good case for this, and I'm changing my position to
neutral.  What I think is more important is to align ping and ping6 more
to reduce code duplication.  If that happens to lead to using normal
getaddrinfo() selection defaults for IPv4 vs IPv6, that is probably a
good thing for system-wide consistency.

/Simon
signature.asc (application/pgp-signature, 1.2 KB)
-----BEGIN PGP SIGNATURE-----

iQNoBAEWCAMQFiEEo8ychwudMQq61M8vUXIrCP5HRaIFAmgiXLIUHHNpbW9uQGpv
c2Vmc3Nvbi5vcmfCHCYAmDMEXJLOtBYJKwYBBAHaRw8BAQdACIcrZIvhrxDBkK9f
V+QlTmXxo2naObDuGtw58YaxlOu0JVNpbW9uIEpvc2Vmc3NvbiA8c2ltb25Aam9z
ZWZzc29uLm9yZz6IlgQTFggAPgIbAwULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgBYh
BLHSvRN1vst4TPT4xNc89jjFPAa+BQJn0XQkBQkNZGbwAAoJENc89jjFPAa+BtIA
/iR73CfBurG9y8pASh3cbGOMHpDZfMAtosu6jbpO69GHAP4p7l57d+iVty2VQMsx
+3TCSAvZkpr4P/FuTzZ8JZe8BrgzBFySz4EWCSsGAQQB2kcPAQEHQOxTCIOaeXAx
I2hIX4HK9bQTpNVei708oNr1Klm8qCGKiPUEGBYIACYCGwIWIQSx0r0Tdb7LeEz0
+MTXPPY4xTwGvgUCZ9F0SgUJDWRmSQCBdiAEGRYIAB0WIQSjzJyHC50xCrrUzy9R
cisI/kdFogUCXJLPgQAKCRBRcisI/kdFoqdMAQCgH45aseZgIrwKOvUOA9QfsmeE
8GZHYNuFHmM9FEQS6AD6A4x5aYvoY6lo98pgtw2HPDhmcCXFItjXCrV4A0GmJA4J
ENc89jjFPAa+wUUBAO64fbZek6FPlRK0DrlWsrjCXuLi6PUxyzCAY6lG2nhUAQC6
qobB9mkZlZ0qihy1x4JRtflqFcqqT9n7iUZkCDIiDbg4BFySz2oSCisGAQQBl1UB
BQEBB0AxlRumDW6nZY7A+VCfek9VpEx6PJmdJyYPt3lNHMd6HAMBCAeIfgQYFggA
JgIbDBYhBLHSvRN1vst4TPT4xNc89jjFPAa+BQJn0XTSBQkNZGboAAoJENc89jjF
PAa+0M0BAPPRq73kLnHYNDMniVBOzUdi2XeF32idjEWWfjvyIJUOAP4wZ+ALxIeh
is3Uw2BzGZE6ttXQ2Q+DeCJO3TPpIqaXDAAKCRBRcisI/kdFohYpAQCZvrTKnkAt
wlafB8rZK2pXUdYqkwXgTl4nCvldNKpduwD+P8Qq1D/qSCoCasT2q2IKMNOr19px
oA9zRRKhHn79lAg=
=9prG
-----END PGP SIGNATURE-----