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/

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

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

Another day, another reason ipv6 should have been ipv4 with more bits.

Unrelated to the article, but the scope ID in IPv6 addresses is super useful for the networking software I write.

The socket API for IPv4 requires a strange ceremony of calling if_nametoindex to map an interface name to an index then setting IP_BOUND_IF in order to bind a socket to a particular network interface. (Sorry, this only works on BSD and Mac OS; Linux instead uses SO_BINDTODEVICE for whatever reason).

When you don't supply a network interface, the OS "helpfully" guesses an interface, and that interface is usually the wrong one for multicast and broadcast packets.

I made a PXE boot server in Rust recently, and I lost at least 30 minutes of my time figuring out why DHCP responses wouldn't be receieved by an EFI client. The problem was that 255.255.255.255:68 is inherently ambiguous when multiple network interfaces exist.

In the case of the IPv6 API, you have to specify the interface up front (e.g. ff05::1:3%en0) or else you won't even be able to send a packet. I used to find this design tedious, but I prefer writing scope IDs explicitly in an address rather than having libc (or my own code) iterate over a linked list provided by the kernel to get an integer then supply that integer to a setsockopt (and remember that Linux has a quirk here).

I think the answer is very obvious here: Debug should not omit fields. serde should not skip fields. Which means that there needs to be a way to put flowinfo into textual representation. Since there are already incompatibilities in how ipv6 addresses are handled ("%enp4s0f0" is supported by ping but not by Rust), might as well make something up, like "1234::5678%9-Q0x42". Tools like "ping" accept "-Q 0x42" option already, so most network engineers would be able to guess what does "-Q0x42" tacked to the end of address means.

Since this is backward-compatible when QoS is not set, I'd just change Display to emit it. But I am guessing some people may complain, so special implementation for Debug would work too...

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.