What’s New with the Flow Label?

The IPv6 Flow Label specification has been updated by the IETF as of November, 2011, and includes changes and refinements that should make the Flow Label more useful in the near term.

IT networking specialists have considered the Flow Label “underspecified” since the first IPv6 specifications were written in the mid 1990s.  As a result, this 20-bit field carried in the IPv6 base header has been a bit of a waste, and has been little used.

In brief, there are three (3) IETF RFCs related to the Flow Label recently published.  Below is a brief digest of each:

RFC 6436 (Informational) is titled “Rationale for Update to the IPv6 Flow Label Specification”, and provides just that.  It provides a description of perceived shortcomings of the previous specification (RFC 3697) and makes recommendations on changes.  The most important bits of information in this RFC are:

  • RFC 3697 requires that only the source node set a Flow Label, and that the Flow Label be delivered intact to the destination node.  This means the Flow Label cannot be set by intermediate nodes, unlike the DSCP sub-field in the IPv6 Traffic Class field.
  • Because the Flow Label is not covered by any checksum, and it is not covered by IPsec protections (not even the Authentication Header), the field cannot really be trusted to not be changed accidentally or overtly along the path from source to destination.
  • The new RFC makes recommendations on updates to the Flow Label, which are specified more authoritatively in RFC 6437.

RFC 6437 (Proposed Standard) is titled “IPv6 Flow Label Specification”, and replaces the previous standard (RFC 3697).  Important elements of the new standard include:

  • Noting that the default implementation of the Flow Label is “stateless”, but that future other uses based on a signaling mechanism are not precluded.
  • Noting that the envisioned use case for stateless Flow Labels involves load-balancing traffic, either in the case of Equal Cost MultiPath (ECMP) or Link Aggregation (LAG) implementations.
  • Encourages source nodes to set Flow Labels, with a unique label per flow
  • Restates that Flow Labels should be well-distributed (random) and not guessable
  • IMPORTANT – removes the restriction that only the source node may set a Flow Label, making it permissible for any device to set a non-zero Flow Label in an IPv6 header where the Flow Label was previously zero (so, an intermediate node may set a Flow Label, but not re-set it)
  • UPSHOT HERE – this new permissiveness means that a router – perhaps the distribution-layer router – can set a Flow Label for flows that do not have them, making the Flow Label useful to other routers, further downstream, that may be performing ECMP or LAG.  The router can take action on the Flow Label where the host did not.  This is a little like an ingress router doing QoS classification and marking for the benefit of downstream routers.
  • The new specification also makes it permissible, on occasion, in high-security environments, for an intermediate node to set a non-zero Flow Label to zero, in an effort to eliminate the possibility of a covert channel being implemented in Flow Label values.
  • The RFC states numerous other possible security issues related to the Flow Label

RFC 6438 (Proposed Standard) is titled “Using the IPv6 Flow Label for ECMP and LAG in Tunnels”.  It describes a way by the Flow Label can be used as the title suggests.  The scenario is that a tunnel has been built where the tunneled traffic passes through a set of devices implementing LAG.   In brief it works like this:

  • Normally, tunnel traffic frustrates the LAG load-balancing algorithm.  Think about it.  If the traffic were not in a tunnel, the individual flows would be apparent – the traffic would be a collection of flows between varying sources and destination, and for different protocols and L4 services (the “5-tuple” would be available for load-balancing).  Because the traffic is tunneled, all traffic yields the same 5-tuple at the downstream LAG, where there is a single source (one end of the tunnel), a single destination (the other end of the tunnel), on protocol (perhaps IP-in-IP, or perhaps GRE).  In other words with the tunnel all traffic looks like a single “massive flow” to the LAG.
  • For a solution, the RFC describes a mechanism whereby the ingress Tunnel End-Points (TEP) examine the tunnel traffic as it enters the tunnel, and then write a Flow Label into the *outer* IPv6 base header based on the 5-tuple of the *inside* packets.  In short, the TEP and the Flow Label turn the “single massive flow” back into individual flows.  The LAG then load-balances on the IPv6 3-tuple (source, destination, Flow Label), and the balancing can be efficient.

That’s the quick wrap-up for all three (3) related RFCs.  IPv6 refinement continues apace, and the protocol continues to evolve gracefully to match the needs of a global scope network.