SocketAddrV6 is not roundtrip serializable

Hm, it has always failed for me on Debian.

In my opinion, flowinfo ought to be used for at least one specific purpose: tagging for networks that (for whatever reason) are not bound by net neutrality, so that they can stop making assumptions based on the ports, which are a layer 4 field, and instead only use layer 3 data as part of their routing. Now it's fair to say most if not all wired ISPs should stop trying to play network neutrality avoidance games, however it is the reality that the packet radio service ("data") of wireless providers, on the other hand, only works at all because they aggressively categorize flows based on the source and destination addresses and especially their ports (TCP or UDP); for background, the keywords to look for are "extended packet core", "IP multimedia subsystem" or "IP multimedia core network subsystem", "rx reference point", "mb2 reference point", etc.

That reliance on layer 4 data means it is challenging to deploy a new transport protocol (such as SCTP) that even just crosses these networks; in fact, the trend these days for protocol design is to encrypt everything, even data that is not particularly sensitive (cf QUIC, on which HTTP/3 is based), in order to avoid such middleboxes growing dependent on data they should never have been able to read, and thus avoid the resultant fossilisation of the Internet protocols.

But this case of wireless networks shows there can be some justification to the routing part of the network treating different flows differently, if only on an opt-in basis, and IPv6 flowinfo is probably the best mechanism for such categorization/tagging where the sender does not request a particular level of services but does mark its data as being in a particular category, probably a dynamic one. Unfortunately, it is unlikely to be meaningfully used as long as IPv4 remains in wide use: until this changes, these networks will need a solution that works for IPv4 (which has ToS but no flowinfo, and too few ToS bits for it to be used for dynamic flow categorization, even after a redefinition -- fun fact: the IPv4 ToS field supplanted a previous definition for that field, then known as DiffServ), and the path of least resistance means they will just apply that solution for IPv6 as well.

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/