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-----