IPv6 Flow Label Specification
obsoleted by
- rfc-6437 — IPv6 Flow Label Specification
Extracted elements (22)
The 3-tuple of Flow Label, Source Address, and Destination Address enables efficient IPv6 flow classification using only fixed-position main header fields. This avoids dependence on fields that may be unavailable due to fragmentation or encryption, or that require traversing a chain of IPv6 option headers to locate.
The Flow Label field alone makes poor material for a hash key, which is why nodes MUST NOT assume mathematical properties of Flow Label values and router performance SHOULD NOT depend on their distribution. This prevents routers from being built with assumptions that could be exploited to cause load imbalance.
This specification sets minimum requirements for flow labeling and flow state establishment co-existence, but deliberately leaves specific flow state establishment methods and service models to separate specifications. This allows different methods to co-exist in IPv6 nodes without mandating a single approach.
A source node MUST ensure it does not unintentionally reuse Flow Label values currently in use or recently used when creating new flows. Flow Label values previously used with a specific address pair MUST NOT be assigned to new flows with the same address pair within 120 seconds of the termination of the previous flow.
Flow state establishment methods MUST be able to recover from the case where the requested flow state cannot be supported.
Flow state establishment methods MUST provide the means for flow state clean-up from the IPv6 nodes providing flow-specific treatment. Signaling-based methods involving the source node may specify flow state lifetimes longer than the default 120 seconds.
If an IPv6 node is not providing flow-specific treatment, it MUST ignore the Flow Label field when receiving or forwarding a packet.
IPv6 nodes MUST NOT assume any mathematical or other properties of the Flow Label values assigned by source nodes. Router performance SHOULD NOT be dependent on the distribution of Flow Label values, and Flow Label bits alone make poor material for a hash key.
Nodes keeping dynamic flow state MUST NOT assume packets arriving 120 seconds or more after the previous packet of a flow still belong to the same flow, unless a flow state establishment method defines a longer lifetime or the flow state has been explicitly refreshed within the lifetime duration.
Source nodes SHOULD assign each unrelated transport connection and application data stream to a new flow to enable Flow Label based classification. A source node which does not assign traffic to flows MUST set the Flow Label to zero.
The Flow Label value set by the source MUST be delivered unchanged to the destination node(s). Intermediate nodes must not alter the field.
The initial Flow Label value SHOULD be derived from a previous value stored in non-volatile memory, or in the absence of such history, a randomly generated initial value using techniques that produce good randomness properties SHOULD be used.
The source node MUST provide means for applications and transport protocols to specify the Flow Label values to be used with their flows, subject to appropriate privileges. The source node SHOULD be able to select unused Flow Label values for flows not requesting a specific value.
To avoid accidental Flow Label value reuse, the source node SHOULD select new Flow Label values in a well-defined sequence (e.g., sequential or pseudo-random) and use an initial value that avoids reuse of recently used values each time the system restarts.
Inspection of unencrypted Flow Labels may allow some forms of traffic analysis by revealing structure of the underlying communications. Even if the Flow Label were encrypted, its presence as a constant value in a fixed position might assist traffic analysis and cryptanalysis.
The IPv6 header contains a 20-bit Flow Label field used by a source to label packets of a flow. A Flow Label of zero indicates packets not part of any flow. Packet classifiers use the 3-tuple of Flow Label, Source Address, and Destination Address to identify which flow a packet belongs to.
An adversary may obtain better service by modifying the IPv6 header or injecting packets with false addresses and/or Flow Labels. Such theft-of-service can become a denial-of-service attack when modified or injected traffic depletes forwarding resources. The risk is closely related to address spoofing because flows are identified by the 3-tuple.
IPsec requires that the inner header's Flow Label not be changed by tunnel decapsulation processing, preventing label manipulation from being used to launch theft or denial-of-service attacks across an IPsec tunnel endpoint. When the tunnel uses a sufficiently strong cryptographic integrity check, the egress node can trust the inner Flow Label matches its value at ingress.
Only applications with appropriate privilege in a sending host are entitled to set a non-zero Flow Label. Mechanisms for enforcing this are operating system dependent, and authorization policy (e.g., per-user restrictions on a multi-user host) is outside the scope of this specification.
The Flow Label does nothing to eliminate the need for packet filtering based on headers past the IP header; firewalls and filtering routers that require such filtering for security reasons must continue to perform it.
The IPsec protocol does not include the IPv6 header's Flow Label in any cryptographic calculations (in tunnel mode, the outer header's Flow Label is excluded). Therefore IPsec provides no defense against modification of the Flow Label by a network node.
The Flow Label is a 20-bit field in the IPv6 main header at a fixed position. It is used in combination with the fixed-position Source Address and Destination Address fields to form a 3-tuple flow identifier, enabling classification without parsing extension headers or upper-layer fields.