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.
47
14