What is the 20-bit IPv6 Flow Label for, and what does RFC 6437 require of sources and forwarding nodes?
answer
- fixed position, no port parsing
- label plus two addresses
- zero means unlabelled
- uniform values, not sequential
- hash it with other fields
basics
~20 sThe IPv6 Flow Label lets a source tag a flow so routers can recognise it from label and addresses, without parsing ports. RFC 6437: sources pick uniform-looking values or zero; forwarders leave non-zero labels alone and never hash on the label alone.
solid answer
~50 sThe Flow Label is a 20-bit field in the base header. With the source and destination addresses it identifies a flow using only fields at fixed positions, which matters when transport ports sit behind an extension-header chain, are missing from non-first fragments or are encrypted by ESP. Its main use is stateless load distribution across ECMP and link-aggregation paths. RFC 6437 says zero means unlabelled; a source should give each transport connection its own label, the same on every packet, drawn from something close to a uniform distribution, and sequential values are not recommended. A forwarding node must leave a non-zero label unchanged except for compelling security reasons, may set one when it arrives as zero, and must combine the label with other packet fields when hashing, because nothing guarantees its values are well distributed.
go deeper
Recall that the IPv6 base header carries a 20-bit Flow Label, and that zero means the source did not label the packet.
Explain the 3-tuple of label and two addresses, and why a fixed-position identifier helps when ports are hard to reach.
Show the load-balancing judgment: labels must be combined with other fields in a hash, never trusted alone, because nothing verifies them and an attacker can forge or cycle them.
Weigh relying on labels across networks you do not control: they help only where sources set them well and middleboxes leave them alone, so designs must degrade cleanly to the 5-tuple.
## What the field is The **Flow Label** is the 20-bit field in bits 12-31 of the IPv6 base header. RFC 8200 defers its definition to **RFC 6437** (2011), which replaced the earlier flow-label specification, RFC 3697, and the flow-label text of RFC 2460. A label of **zero** means the packet is unlabelled. A classifier identifies a flow by the **3-tuple** of Flow Label, Source Address and Destination Address. ## Why a label at all The usual way to recognise a flow is the 5-tuple: addresses, protocol, and source and destination ports. In IPv6 a forwarding device cannot always reach the ports: - they can sit behind a **chain of extension headers** that is costly to walk; - a **non-first fragment** carries no transport header at all; - **ESP** encrypts them. The label sits at a fixed offset in the base header, so classification needs nothing beyond the first 40 bytes, and it keeps working for transport protocols a device has never heard of. RFC 6437's stated goal is to encourage **stateless load distribution** across **ECMP** (equal-cost multipath routing) and **link aggregation** groups, where every packet of a flow must take the same path to avoid reordering. ## Rules for sources - A source **should** assign each unrelated transport connection and application data stream to a new flow, typically one per 5-tuple. - It is **recommended** that every packet of a flow carry the same label, chosen from an approximation of a **discrete uniform distribution**, so the bits vary well as hash input and an outsider cannot guess the next value. - Two methods are named: a 20-bit hash of the 5-tuple, or a pseudo-random value stored per socket. - Assigning labels **sequentially is NOT RECOMMENDED**, because an on-path observer could predict them. - A source that does not otherwise set the label **must** set it to zero. ## Rules for forwarding nodes 1. Once non-zero, the label is expected to arrive unchanged. A forwarding node **must** leave a non-zero label as it is, or change it only for compelling operational security reasons. 2. A node forwarding a flow whose label arrives as zero **may** set one, and should then choose values as a source would. 3. A forwarding node **must not** depend only on the label being uniformly distributed. When it is used as hash input it **must** be combined with other packet fields, typically parts of the 5-tuple, so traffic still spreads if labels are poor or zero. 4. A zero label does **not** mean reordering is acceptable; flows should not be reordered either way. | Actor | Expected to | Must not (or should not) | |---|---|---| | Source | Give each flow one uniform-looking value, or send zero | Assign labels sequentially (not recommended) | | Forwarding node | Leave non-zero labels as they arrive; may label a flow arriving with zero | Change a non-zero label without a compelling security reason | | Load balancer | Use the label as one hash input among others | Hash on the label alone | | Firewall rewriting labels | Rewrite as if the label had arrived as zero | Set a non-zero label to zero | ## Limits and security - The label is **unprotected**: no checksum covers it and nothing proves it was not altered. RFC 6437 calls its quality best effort. - An attacker able to forge addresses can forge labels too, for example setting every label to one value, or cycling them, to defeat a load-distribution scheme. That is why the label must never be the sole hash input. - The label can carry a **covert channel**. Where that risk matters, a firewall may rewrite non-zero labels, an explicit exception to the do-not-change rule; it should rewrite them as if they had arrived as zero and must not set a non-zero label to zero. - Stateful uses, where nodes keep per-flow state set up by signalling, are allowed but outside RFC 6437's scope; the label alone reserves nothing. In an interview, the strong answer is the 3-tuple and the reason for it: a fixed-position flow identifier for devices that cannot or should not parse further, with the rule that it supplements the 5-tuple rather than replacing it.
- Why can the IPv6 Flow Label help a router more than transport ports for some traffic?Ports may be unreachable from the network's point of view: hidden behind a chain of extension headers, absent from every fragment after the first, or encrypted by ESP. The label sits at a fixed offset in the base header, so a router can identify the flow from label and addresses alone.
- Does a zero IPv6 Flow Label tell the network it may reorder that flow's packets?No. RFC 6437 states that a zero label does not imply reordering is acceptable; packet flows should not be reordered whatever the label says. Zero only means the source did not label the packet.
saying these in an interview costs you the question
- Setting a Flow Label reserves bandwidth for that flow on every router.
- Routers can hash on the Flow Label alone because sources make it uniform.
- A zero Flow Label tells routers the flow tolerates reordering.
- Routers rewrite the Flow Label at every hop, as they do Hop Limit.
- The Flow Label is protected by the IPv6 header checksum.