The IPv6 fixed header is pictured below; at 40 bytes, it is twice the size of the IPv4 header. The fixed header is intended to support only what every packet needs: there is no support for fragmentation, no header checksum, and no option fields. However, the concept of extension headers has been introduced to support some of these as options; some IPv6 extension headers are described in 8.5 IPv6 Extension Headers. Whatever header comes next is identified by the Next Header field, much like the IPv4 Protocol field. Some other fixed-header fields have also been renamed from their IPv4 analogues: the IPv4 TTL is now the IPv6 Hop_Limit (still decremented by each router with the packet discarded when it reaches 0), and the IPv4 DS field has become the IPv6 Traffic Class.
The Flow Label is new. RFC 2460states that it
may be used by a source to label sequences of packets for which it requests special handling by the IPv6 routers, such as non-default quality of service or “real-time” service.
Senders not actually taking advantage of any quality-of-service options are supposed to set the Flow Label to zero.
When used, the Flow Label represents a sender-computed hash of the source and destination addresses, and perhaps the traffic class. Routers can use this field as a way to look up quickly any priority or reservation state for the packet. All packets belonging to the same flow should have the same Routing Extension header, 8.5.3 Routing Header. The Flow Label will in general not include any information about the source and destination port numbers, except that only some of the connections between a pair of hosts may make use of this field.
A flow, as the term is used here, is one-way; the return traffic belongs to a different flow. Historically, the term “flow” has also been used at various other scales: a single bidirectional TCP connection, multiple related TCP connections, or even all traffic from a particular subnet (eg the “computer-lab flow”).