One immediate example would be to start having "L4/L5 description" fields in the former flow label. A few examples could be
In the Former Flow Label (FFL)
1. FFL bit 19: "Escape" - alternative semantics for the flow label field
2. FFL bit 18: "Extended info available in L3 option headers" - (i) L4 and/or L5 description extended info available for this protocol, and/or connection and/or for this packet or the current context; L4 retx timeout info will be given; (ii) anti-tampering info may be present; (iii) firewall info may be present
3. FFL bit 17: "Extended info available in L3 header itself" - in alt. fields - tbs
Also either in the FFL, or housed elsewhere in the IPv6 header
1. "packet does not contain L4 ports at start", note negated polarity
2. "packet will be retransmitted if necessary",
3. "packet is a retransmission",
4. "packet is part of an L4 (re-)connect sequence", - firewalls can not drop first-received packets just because this is not set, order could have been switched, or the protocol could simply be non-connection-oriented eg plain UDP
5. "packet contains an L4 ack", or a connect_ack
6. "packet is part of slow-start type sequence"
7. "L5 payload:xxx"
8. "L5 payload:xxx"
9. "L5 payload:xxx" 000 = contains no L5 payload, otherwise contains L4 SDUs;001 = "contains an L5 query" in the sense that the sender is blocked, waiting, until a response is received related to this; 010="contains a response to a query", 011="contains a response and a second query " - these three values used if the application layer is doing a stop-and-wait application-layer protocol at the moment; 100 and 101 ="single L4 SDU" / "small finite known L4 SDU" - not a query or a response - a single modest-sized L5 data unit, either one L4 SDU or else a part of a small group of L4 SDUs sent together back-to-back, after which the sender will pause - 101 is the same as 100 but slightly bigger, this in contrast to a continuous sequence; 110="stream sequence (flat out)" meaning that this packet contains L5 payload that is part of a stream of packets (not limited by L4 or L5 stop-and-wait), that is, like TCP doing a file transfer, or like an http download or a streaming protocol, does not imply real time streaming or no acks or no retx, attempts to go as fast as possible, assume it has a tuning mechanism; 111="stream sequence, rate limited" - as prev, but not flat out, either suitably rate limited to a fixed rate well below the link capacity, chosen to avoid congestion, or a background 'trickle' flow e.g. based on triggers from network inactivity time
10. "do not drop this packet", can not be relied upon, strong recommendation. it increases the no_drop_priority of the packet by +=1
11. "delay this packet" - can delay this packet slightly for throttling purposes, should consult retx timeout info if present
12. "avoid packet reordering in this flow"
13. "is L4 fragment xx"
14. "is L4 fragment xx" - is part of multi-L4 (or higher) PDU all-or-nothing sequence, more than a single PDU. This is where fragmentation is being done at L4 (or higher) for the particular Lx SDU, whichever layer: always tells receiver whether or not an entire sequence of n >=2 packets will be _retransmitted from the start_ if this fragment is dropped or if there is an ack timeout. Implies "avoid reordering of packets in this flow". Values of this two-bit field are "is L4 fragment: first"=01, "middle" =10, "last"=11, and "not a fragment" =00. Must never be used unless more than one fragment. Implies 'do not drop' if this is not the first fragment, or if this is the first fragment but is seen out of sequence. If the actual "do not drop flag" is set, that increases the no-drop priority even further. This contributes an even higher no_drop_priority +=2, say, compared with the "do not drop" flag, which is say worth no_drop_priority += 1