[majke]

Falsehoods programmers think about addresses:

- parsing addresses is well defined (try parsing ::1%3)

- since 127.0.0.2 is on loopback, ::2 surely also would be

- interface number on Linux is unique

- unix domain socket names are zero-terminated (abstract are not)

- sin6_flowinfo matters (it doens;t unless you opt-in with setsockopt)

- sin6_scope_id matters (it doesn't unless on site-local range)

(I wonder if scope_id would work on ipv4-mapped-IPv6, but if I remember right I checked and it didn't)

- In ipv4, scope_id doesnt exist (true but it can be achieved by binding to interface)

and so on...

Years ago I tried to document all the quirks I knew about https://idea.popcount.org/2019-12-06-addressing/

[sunshowers]

Thanks. At Oxide we do use the scope ID quite a bit, as my colleague Cliff Biffle says here: https://hachyderm.io/@cliffle/115492946627058792

[namibj]

It's sad that the only other loopback v6's appear to be v4's /8 in the form mapped into a slice of v7 address space

[o11c]

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

[mananaysiempre]

> you can't ping it

WTF?..

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

[heinrich5991]

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

[mananaysiempre]

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]

Hm, it has always failed for me on Debian.