[PATCH 1/1] ping: Add support for IPv4-mapped IPv6 address format

[Lars Uffmann]

Hi all,

Petr asked me to subscribe and post my opinion here - due to the context I subscribed using my realname (repo) address instead of my spamcatcher :)

Honestly, I went into this quite naive just thinking ping should probably be able to work with ipv4 mapped ipv6 addresses, and asked an according question on the debian matrix chat.
What I didn't know was whether there was any valid context in which an ipv4-mapped ipv6 address would ever be able to get an ICMP response.

While there was some discussion, Tj went ahead and proposed an implementation, from which I gathered that no, there is no way to reach an ipv6 destination with such an address, because it is really just a way to encode an ipv4 destination while using the same socket functions.

If indeed there is something that could be broken by such a feature to ping, then I won't be the one to insist "you absolutely should implement it anyways" :)

As for the points David brings up:

On 2024-10-20 13:51:32, Petr Vorel wrote:
>>> I'm not a fan of this patch because ping is a low-level diagnostic tool.

While I would acknowlege the low-level diagnostic part, I do think it has uses that go beyond that - since most operating systems can be configured to respond to ICMP requests, it can be used as an automatic link detection tool (which I do, in one of my applications), in which case the patch would be quite useful, because it'd be up to the user to configure a link destination in whatever ip format / hostname they desire.

>>> Sadly, this patch breaks the case where an advanced user wants ping
>>> to send a packet with an IPv4-mapped IPv6 addresses. For example, you
>>> might be testing or diagosing firewall rules in that subnet.

So @David: does that mean when you send such a packet with a destination ::ffff::<ipv4>, it would actually match some network route so that it could reach a firewall?

In that case, yes, that's the kind of compatibility breakage that I wouldn't want to cause, and I'd agree on the "sadly" bit :D

However, I also believe that the usefulness of this patch is greater than the usefulness of
>>> the case where an advanced user wants ping to send a packet with an IPv4-mapped IPv6 addresses

and therefore, while I wouldn't advocate for changing the default application behavior,

>>> Additionally, I can't see any combination of -4 or -6 option flags that
>>> could be used as a guard to make the unmapping behaviour expected.

Actually, reading this line of yours, I could see exactly one combination that should not not break any existing application:
Assume we want an ipv4 ping out of an ipv6 address (that masks an ipv4). So we kind of want a hybrid behavior of 4 and 6, don't we?

How about
   ping -4 -6 ::ffff::<ipv4>
triggering the new functionality that unmasks such an address (or hostname)?

I checked and normally you get

$ ping -4 -6 localhost
ping: only one -4 or -6 option may be specified

So this combination of options is currently unique, and could be used like so

https://github.com/iputils/iputils/commit/25c1a958e68bf6b4a6065a8ec6015a141d68bbac

to make the functionality available without breaking existing functions.


>>> I can only speculate on what what they were trying to do. I suspect their
>>> program accepted on an IPv6 listener socket, passed the peer's address to
>>> inet_ntop(), got "::ffff:1.2.3.4", constructed a "ping %s" for system()
>>> and found that, becoming a raw wire address, it was promptly dropped by
>>> a route table or firewall.

No need to speculate anymore, I am here to tell you :)

I have experimented with link detection by ping:

https://codeberg.org/lars_uffmann/json2ccsds/src/commit/7740e1327b4d310458cfb517b30fee793eb265f6/src/json2ccsds/json2ccsds.cpp#L925

For my own application, I might end up implementing an ICMP socket directly, mostly to avoid the unnecessary system call in the exec routine.

But while experimenting, I noticed that ping with such mapped ipv4 addresses didn't work, and was wondering why.

> Maybe Lars can explain the reasons.

I hope to have done so sufficiently :) So please do not mistake my request for a "I need this for my application" - I can solve this in code myself. I didn't even think about submitting a patch to a linux core utility (I have never submitted anything to the linux toolset before), but when I saw Tj just implemented it, and that Petr apparently thought it was a good idea, I figured I might as well propose a patch that does this unmasking of the mapped address after hostname resolution.

Again - I have no strong feelings about this, I do not demand anything, but I do think this would be useful.

Maybe even implement a -5 option as it is a great hybrid between 4 and 6 (I am only half joking :)

Kind regards
    Lars