You can use ::ffff:127.0.0.2 for most purposes, but you can't ping it.

mananaysiempre · 2025-11-05T17:28:53 1762363733

> you can't ping it

WTF?..

(My Linux machine can, but I’ve no clue if I should trust that now.)

heinrich5991 · 2025-11-16T22:32:51 1763332371

Doesn't work on my Arch Linux. Neither does pinging ::ffff:127.0.0.1. Pinging 127.0.0.1 and ::1 works.

mananaysiempre · 2025-11-17T13:09:53 1763384993

I think I know what's going on: iputils[1] ping can't ping IPv6-mapped IPv4 addresses, but inetutils[2] ping can. And look inside the parens:

  $ ping ::ffff:127.0.0.1
  PING ::ffff:127.0.0.1 (::ffff:127.0.0.1) 56 data bytes

says the non-working one,

  $ ping ::ffff:127.0.0.1
  PING ::ffff:127.0.0.1 (127.0.0.1): 56 data bytes

says the working one. In Wireshark, the latter appears as ICMPv4 packets on the lo interface, whereas the former does not appear at all(?..). So overall this makes some amount of sense: you can write a TCP-using program that's agnostic to whether it's running on top IPv4 or IPv6, but you have to use different ICMP versions for IPv4 and IPv6. I actually don't know why it has to be that way.

(My initial confusion was because I thought 'o11c was saying they could ping ::ffff:127.0.0.1 but not .2. It makes much more sense for either both or neither to be pingable.)

[1] https://github.com/iputils/iputils (the one that comes with the bizarre tracepath thing)

[2] https://www.gnu.org/software/inetutils/

o11c · 2025-11-05T18:44:29 1762368269

Hm, it has always failed for me on Debian.