sin6_flowinfo field added to struct sockaddr_in6
(see RFC2553).
1cm NB.
This method is difficult to consider as reasonable, because it
puts additional overhead to all the services, despite of only
very small subset of them (none, to be more exact) really use it.
It contradicts both to IETF spirit and the letter. Before RFC2553
one justification existed, IPv6 address alignment left 4 byte
hole in sockaddr_in6 in any case. Now it has no justification.
We have two problems with this method. The first one is common for all OSes:
if recvmsg() initializes sin6_flowinfo to flow info
of received packet, we loose one very important property of BSD socket API,
namely, we are not allowed to use received address for reply directly
and have to mangle it, even if we are not interested in flowinfo subtleties.
1cm NB.
RFC2553 adds new requirement: to clear sin6_flowinfo.
Certainly, it is not solution but rather attempt to force applications
to make unnecessary work. Well, as usually, one mistake in design
is followed by attempts to patch the hole and more mistakes...
Another problem is Linux specific. Historically Linux IPv6 did not
initialize sin6_flowinfo at all, so that, if kernel does not
support flow labels, this field is not zero, but a random number.
Some applications also did not take care about it.
1cm NB. Following RFC2553 such applications can be considered as broken, but I still think that they are right: clearing all the address before filling known fields is robust but stupid solution. Useless wasting CPU cycles and memory bandwidth is not a good idea. Such patches are acceptable as temporary hacks, but not as standard of the future.