Summary

  • The 20-bit IPv6 Flow Label gives routers and load balancers fixed-position input for treating packets as one flow even when ports are hidden, fragmented or costly to locate.
  • Its value depends on a strict combination: one stable non-zero value within a flow, broadly distributed values across flows, restraint against changing labels in transit, and classification that never trusts the label alone.
  • RFC 6437 moved the design away from RFC 3697's more state-oriented model; RFC 6438 and RFC 7098 then described bounded uses in tunnels and server farms.

A handle, not an identity

The Flow Label occupies twenty bits in the fixed IPv6 header. A value of zero says only that the packet is unlabeled. A classifier can combine a non-zero label with source and destination addresses, producing a three-field key that remains available before any search through extension headers or encrypted transport material.

That modest definition is the first important boundary. An IPv6 flow need not equal a transport connection. The label does not name an application, user or session, and it carries no proof of who set it. RFC 6437 nevertheless recommends that unrelated transport connections or application streams normally be placed in distinct flows. The field is therefore a classification handle whose meaning is supplied by consistent packet treatment, not a declaration of application semantics.

At the source, every packet in one flow should receive the same non-zero label. Values across flows should approximate a discrete uniform distribution and be hard to predict. A source might hash a five-tuple into twenty bits or assign a pseudo-random value while keeping minimal state, but those are examples rather than prescribed algorithms. Sequential allocation is discouraged because it distributes poorly and is easier to anticipate.

Twenty bits do not make labels unique. Two simultaneous flows sharing the same source and destination can collide. When that happens, a label-based device cannot separate them: both receive the same label-based treatment. The design accepts that result. It seeks useful distribution and affinity, not a globally unique flow identifier.

Why the fixed position mattered

Traditional load distribution often hashes transport ports. IPv6 makes that input less dependable for an intermediate device: ports may be absent from non-initial fragments, concealed by encryption, or located only after walking an extension-header chain. The Flow Label is always in a known place in the IPv6 header. This does not reveal the ports; it provides other material that a device can use without finding them.

RFC 6438 applies that property to an IP-in-IPv6 tunnel. If every packet carries identical outer addresses, an ECMP or link-aggregation hash based only on those addresses can polarize traffic onto one path. The sending tunnel endpoint can instead derive an outer Flow Label from an inner two- or five-tuple, hold that label constant for the inner flow and allow different inner flows to spread across available paths. Occasional collisions remain acceptable: two user flows may share one path treatment without becoming the same flow.

RFC 7098 carries the same idea to layer 3/4 server load balancing. A device may use source address plus Flow Label, or destination address, source address and Flow Label, as a session key. A stateless balancer can hash that key so packets in a flow return to one server. A stateful balancer can remember the key-to-server association. Packets with a zero label continue through traditional transport-header handling.

State does not erase ambiguity. If a source reuses a label for a new transport session while the addresses remain the same, a stateful balancer cannot distinguish the new session by that key alone. The label preserves classification only inside its stated limits.

The redesign and its restraint

RFC 6437 replaced RFC 3697's earlier model by encouraging non-zero labels, stateless source behaviour and uniformly distributed values. It retained the rule that a non-zero label should arrive unchanged. A forwarder may fill a zero label on a source's behalf, but that function must be configurable and disabled by default; source assignment remains preferred.

This history matters because the field became more useful by asking less of the network. Routers did not need to learn application state or interpret a label's hidden meaning. Sources supplied stable, distributed input; forwarding devices used it as one element of a hash. That is an editorial interpretation of the RFC mechanics, not a claim that every IPv6 deployment follows them.

The sources in this package contain no current deployment census, vendor benchmark or performance measurement. They establish the protocol model and possible uses, not how often operators enable them today.

Sources