ietf-corpus

rfc-6437

IPv6 Flow Label Specification

S. Amante, B. Carpenter, S. Jiang, J. Rajahalme
date2011-11 streamIETF areaint wg6man statusPROPOSED STANDARD pages15 canonicalhttps://www.rfc-editor.org/rfc/rfc6437 doi10.17487/RFC6437
This document specifies the IPv6 Flow Label field and the minimum requirements for IPv6 nodes labeling flows, IPv6 nodes forwarding labeled packets, and flow state establishment methods. Even when mentioned as examples of possible uses of the flow labeling, more detailed requirements for specific use cases are out of the scope for this document. The usage of the Flow Label field enables efficient IPv6 flow classification based only on IPv6 main header fields in fixed positions. [STANDARDS-TRACK]

obsoletes

updates

Extracted elements (25)

design-rationale §2

Flow label values should approximate a discrete uniform distribution to exhibit both high variability (useful for load distribution hashing) and unguessability (resistant to adversarial prediction). No precise mathematical requirements are imposed on the distribution method.

ip

design-rationale §5

The flow label field size was reduced from 24 bits (in an early RFC 2205 reference) to 20 bits in RFC 2460. This document corrects the outdated 24-bit reference in RFC 2205 Section A.9 accordingly.

ip

design-rationale §3

The principal recommendation is that source hosts set the flow label rather than forwarding nodes, because source nodes always have convenient access to the complete 5-tuple, which intermediate routers may not have (e.g., for fragmented packets).

ip

interoperability-note §6 SHOULD

Hash-based flow label generation SHOULD include a step that makes the flow label value significantly difficult to predict (per RFC 4086), even with knowledge of the algorithm, to resist adversarial guessing.

ip, security, crypto

interoperability-note §7

This document obsoletes RFC 3697 and updates RFC 2205 and RFC 2460. The key differences from RFC 3697 include encouraging non-zero flow label values, promoting the stateless model with uniformly distributed values, and allowing routers to set labels on behalf of hosts that do not.

ip

normative-requirement §2 MUST

A forwarding node MUST either leave a non-zero flow label value unchanged or change it only for compelling operational security reasons (covert channel risk). Arbitrary en-route modification is prohibited.

ip

normative-requirement §3 MUST

A source node that does not otherwise set the flow label MUST set its value to zero.

ip

normative-requirement §4 MUST NOT

Any stateful flow state establishment method MUST NOT disturb nodes taking part in the stateless scenario. Nodes setting flow labels via a stateful scheme MUST choose labels that conform to Section 3 (uniform distribution requirements).

ip

normative-requirement §2 MUST NOT

Forwarding nodes such as routers and load distributors MUST NOT depend only on Flow Label values being uniformly distributed. Flow Label bits MUST be combined with bits from other packet fields (e.g., the 5-tuple) when used as a hash key for load distribution.

ip

normative-requirement §3 SHOULD

Source nodes SHOULD assign each unrelated transport connection and application data stream to a new flow, and SHOULD set the flow label field for all packets of a given flow to the same value chosen from an approximation to a discrete uniform distribution.

ip

normative-requirement §3 SHOULD

The algorithm used to generate flow label values SHOULD ensure that resulting values are unique with high probability. Sequential assignment of flow labels is NOT RECOMMENDED because it allows on-path observers to guess the next value.

ip

normative-requirement §3 MUST

The option for a forwarding node to set the flow label on behalf of hosts MUST be a configurable option, disabled by default, to avoid unwanted processing load and undesirable effects.

ip

protocol-element §3

A forwarding node MAY change the flow label of arriving packets whose flow label value is zero. In that case, it is RECOMMENDED that the forwarding node sets the flow label to a uniformly distributed value using the same method recommended for source nodes.

ip

protocol-element §A

An example 20-bit hash function for stateless flow label generation is provided in Appendix A, based on von Neumann's algorithm. It operates on the 5-tuple by splitting addresses into 64-bit halves, summing components, applying von Neumann bit-pair extraction, adding port numbers, and shifting. It does not include a predictability-prevention step.

ip

protocol-element §1

The 3-tuple of Flow Label, Source Address, and Destination Address enables efficient IPv6 flow classification using only main header fields at fixed positions, avoiding dependency on extension headers or transport-layer fields that may be unavailable due to fragmentation or encryption.

ip

protocol-element §1

Two scenarios for flow label usage are defined: stateless (no per-flow state stored before or after packet processing) and stateful (requires stored flow state and possibly signaling such as RSVP or GIST). This specification focuses on the stateless model.

ip

protocol-element §3

When a forwarding node lacks access to the complete 5-tuple (e.g., for fragmented packets), it may define flows using the 2-tuple {dest addr, source addr} instead. This results in unfragmented and fragmented packets of the same transport session receiving different flow label values.

ip

security-consideration §6.2

An attacker could set all flow labels reaching a given router to the same non-zero value or rapidly cycle values, causing stateless load distribution to perform badly and stateful classifiers to behave incorrectly. Stateless classifiers must not use flow label alone; stateful classifiers should detect and ignore suspect values.

ip, security

security-consideration §6

Even if the flow label were encrypted, its presence as a constant value in a fixed position might assist traffic analysis and cryptanalysis, revealing structure of the underlying communications.

ip, security, privacy

security-consideration §6.2

Flow label spoofing enables theft or denial of service: an adversary may obtain unintended QoS treatment by injecting packets with forged addresses and/or labels. Networks SHOULD NOT make resource allocation decisions based on flow labels without external means of assurance.

ip, security

security-consideration §6.3

IPsec tunnel mode protects the inner header's flow label but not the outer header's. The IPsec protocol requires that the inner header's flow label not be changed during decapsulation, preventing theft or denial-of-service attacks across IPsec tunnel endpoints.

ip, ipsec, security

security-consideration §6.1

The flow label can serve as a covert data channel, since pseudo-random values could encode covert messages. The only certain defense is for a firewall to rewrite non-zero flow labels; such a firewall SHOULD reassign labels using the forwarding-node method and MUST NOT set non-zero labels to zero.

ip, security

security-consideration §6.4

The flow label does nothing to eliminate the need for packet filtering based on headers past the IP header. Firewalls and filtering routers must still perform transport-layer header inspection if required for security.

ip, security

security-consideration §6

The flow label is not protected by IPsec authentication (RFC 4302); it can be forged by an on-path attacker without causing any IPsec integrity check to fail. Any en-route modification of the flow label is undetectable.

ip, ipsec, security

wire-format §2

The IPv6 Flow Label is a 20-bit field in the IPv6 header. A value of zero indicates packets that have not been labeled. Packet classifiers use the 3-tuple of Flow Label, Source Address, and Destination Address to identify flows.

ip