1. Introduction

From the viewpoint of the network layer, a flow is a sequence of packets sent from a particular source to a particular unicast, anycast, or multicast destination that a node desires to label as a flow. From an upper-layer viewpoint, a flow could consist of all packets in one direction of a specific transport connection or media stream. However, a flow is not necessarily 1:1 mapped to a transport connection.

Traditionally, flow classifiers have been based on the 5-tuple of the source address, destination address, source port, destination port, and the transport protocol type. However, some of these fields may be unavailable due to either fragmentation or encryption, or locating them past a chain of IPv6 extension headers may be inefficient. Additionally, if classifiers depend only on IP-layer headers, later introduction of alternative transport-layer protocols will be easier.

The usage of the 3-tuple of the Flow Label, Source Address, and Destination Address fields enables efficient IPv6 flow classification, where only IPv6 main header fields in fixed positions are used.

The flow label could be used in both stateless and stateful scenarios. A stateless scenario is one where any node that processes the flow label in any way does not need to store any information about a flow before or after a packet has been processed. A stateful scenario is one where a node that processes the flow label value needs to store information about the flow, including the flow label value. A stateful scenario might also require a signaling mechanism to inform downstream nodes that the flow label is being used in a certain way and to establish flow state in the network. For example, RSVP [RFC2205] and General Internet Signaling Transport (GIST) [RFC5971] can signal flow label values.

The flow label can be used most simply in stateless scenarios. This specification concentrates on the stateless model and how it can be used as a default mechanism. Details of stateful models, signaling, specific flow state establishment methods, and their related service models are out of scope for this specification. The basic requirement for stateful models is set forth in Section 4.

The minimum level of IPv6 flow support consists of labeling the flows. A specific goal is to enable and encourage the use of the flow label for various forms of stateless load distribution, especially across Equal Cost Multi-Path (ECMP) and/or Link Aggregation Group (LAG) paths. ECMP and LAG are methods to bond together multiple physical links used to procure the required capacity necessary to carry an offered load greater than the bandwidth of an individual physical link. Further details are in a separate document [RFC6438]. IPv6 source nodes SHOULD be able to label known flows (e.g., TCP connections and application streams), even if the node itself does not require any flow-specific treatment. Node requirements for stateless flow labeling are given in Section 3.

This document replaces [RFC3697] and Section 6 and Appendix A of [RFC2460]. A rationale for the changes made is documented in [RFC6436]. The present document also includes a correction to [RFC2205] concerning the flow label.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].