Unlike version 4, IPv6 contains a 20 bit “flow label” field inside the header, whose goals is to encode, all at once, the typical 5-tuple (source/destination addresses and ports, plus transport protocol type)
As suggested from RFC6437 one possible application, is to correctly distribute the load between two or more equal cost links, while transporting tunneled traffic: traditional load sharing is performed by looking up the source and destination address of the outmost IP header and then hashing these two parameters.
Unfortunately tunnel endpoints are, in most of the cases, two fixed values, which force traffic to always take the same outgoing interface, instead of sharing multiple paths.
IPv6 flow label is coming into help, so that when traffic is encapsulated, the inner flow-label value will be copied into the outer header, and all the network nodes in between will be able to load share accordingly to that value.
As an additional purpose, an application flow is not always mapped 1:1 to a transport flow, but it can be composed by more of them: a flow label can then encode these transport “sub-flows” as a single flow value, so that hop by hop delivery will be predictable and packets reordering avoided.