Using the IPv6 Flow Label for Equal Cost Multipath Routing and Link Aggregation in Tunnels
Extracted elements (17)
In IP-in-IPv6 tunnels, all outer packets share the same source/destination addresses (the TEPs) and likely the same port and protocol numbers, causing the 2-tuple or 5-tuple hash to be constant and producing polarization — no load sharing across equal-cost paths between R1 and R2.
IPv6 transport-layer fields are inconvenient to extract for hardware because next-headers have variable placement and length; all implementations must be able to skip them. The 20-bit flow label in the fixed IPv6 header is therefore a simpler and more hardware-friendly hash input, especially for tunneled traffic.
RFC 3697 rules 2 and 3 — that routers must not assume mathematical properties of flow labels and that router performance should not depend on their distribution — were intended for the general case where flow state is unknown. A router that has participated in flow state establishment (or knows the TEP's assignment method) can rely on label properties without further signaling, making those rules inapplicable in the tunnel scenario.
Stateless flow label assignment via hashing creates a small probability of two different user flows mapping to the same label, but since RFC 6437 allows a source to define any packet set as a single flow, occasionally labeling two user flows as one through a tunnel is acceptable.
OAM techniques (Operations, Administration, and Maintenance) will need to be adapted to manage ECMP and LAG based on the flow label, analogous to adaptations made for MPLS (RFC 4379) and pseudowires (RFC 6391).
The specification is compatible with both RFC 3697 (original flow label specification) and RFC 6437 (revised flow label specification). RFC 6437 obviates the concerns raised by the three rules quoted from RFC 3697 and is the preferred reference.
Flow label values SHOULD be chosen from a uniform distribution per RFC 6437, making them suitable as hash input and hard for a malicious third party to predict.
Inner packets MUST be encapsulated in an outer IPv6 packet whose source and destination addresses are those of the tunnel endpoints (TEPs).
The flow label in the outer packet SHOULD be set by the sending TEP to a 20-bit value in accordance with RFC 6437. The same flow label value MUST be used for all packets in a single user flow, as determined by the IP header fields of the inner packet.
The hash algorithm used at intermediate routers for ECMP and/or LAG MUST minimally include the 3-tuple {dest addr, source addr, flow label} and MAY also include the remaining 5-tuple components {protocol, dest port, source port}.
The sending TEP MAY perform stateless flow label assignment by using a suitable 20-bit hash of the inner IP header's 2-tuple or 5-tuple as the flow label value. If the inner packet is IPv6, its flow label may also be included in this hash.
The sending TEP MUST classify all packets into flows once it has determined they should enter a given tunnel, then write the relevant flow label into the outer IPv6 header. The choice of 2-tuple, 5-tuple, or 3-tuple for flow identification is an implementation choice.
ECMP and LAG use a modulo(N) hash over defined header fields to distribute traffic across N equally good paths. The hash ensures all packets of a given flow yield the same output, preventing out-of-order delivery while achieving statistical load balance.
In an IP-in-IPv6 tunnel, the tunnel endpoint (TEP) is the source node of the outer packet and is therefore free to set the outer IPv6 flow label. Routers R1 and R2 between TEP A and TEP B can rely on flow labels assigned by a known method to perform ECMP or LAG.
Intermediate IPv6 routers will encounter a mixture of tunneled and normal traffic. The hash design SHOULD include {protocol, dest port, source port} as additional input keys to provide entropy for flows whose flow label is zero, covering non-tunneled traffic.
Off-path attackers are unlikely to guess a valid flow label if an apparently pseudo-random and unpredictable value is used, consistent with the uniform-distribution requirement from RFC 6437.
The IPv6 flow label is unprotected and can be forged by an on-path attacker. The worst an attacker could do against ECMP or LAG is attempt to selectively overload a particular path. Tunnel endpoints and ECMP/LAG paths are expected to be part of a managed infrastructure protected against on-path attacks, for example by using IPsec between tunnel endpoints.