RFC 1883                   IPv6 Specification              December 1995


6.  Flow Labels

   The 24-bit Flow Label field in the IPv6 header may be used by a
   source to label those packets for which it requests special handling
   by the IPv6 routers, such as non-default quality of service or
   "real-time" service.  This aspect of IPv6 is, at the time of writing,
   still experimental and subject to change as the requirements for flow
   support in the Internet become clearer.  Hosts or routers that do not
   support the functions of the Flow Label field are required to set the
   field to zero when originating a packet, pass the field on unchanged
   when forwarding a packet, and ignore the field when receiving a
   packet.

   A flow is a sequence of packets sent from a particular source to a
   particular (unicast or multicast) destination for which the source
   desires special handling by the intervening routers.  The nature of
   that special handling might be conveyed to the routers by a control
   protocol, such as a resource reservation protocol, or by information
   within the flow's packets themselves, e.g., in a hop-by-hop option.
   The details of such control protocols or options are beyond the scope
   of this document.

   There may be multiple active flows from a source to a destination, as
   well as traffic that is not associated with any flow.  A flow is
   uniquely identified by the combination of a source address and a
   non-zero flow label.  Packets that do not belong to a flow carry a
   flow label of zero.

   A flow label is assigned to a flow by the flow's source node.  New
   flow labels must be chosen (pseudo-)randomly and uniformly from the
   range 1 to FFFFFF hex.  The purpose of the random allocation is to
   make any set of bits within the Flow Label field suitable for use as
   a hash key by routers, for looking up the state associated with the
   flow.

   All packets belonging to the same flow must be sent with the same
   source address, destination address, priority, and flow label.  If
   any of those packets includes a Hop-by-Hop Options header, then they
   all must be originated with the same Hop-by-Hop Options header
   contents (excluding the Next Header field of the Hop-by-Hop Options
   header).  If any of those packets includes a Routing header, then
   they all must be originated with the same contents in all extension
   headers up to and including the Routing header (excluding the Next
   Header field in the Routing header).  The routers or destinations are
   permitted, but not required, to verify that these conditions are
   satisfied.  If a violation is detected, it should be reported to the
   source by an ICMP Parameter Problem message, Code 0, pointing to the
   high-order octet of the Flow Label field (i.e., offset 1 within the
   IPv6 packet).



 
RFC 1883                   IPv6 Specification              December 1995


   Routers are free to "opportunistically" set up flow-handling state
   for any flow, even when no explicit flow establishment information
   has been provided to them via a control protocol, a hop-by-hop
   option, or other means.  For example, upon receiving a packet from a
   particular source with an unknown, non-zero flow label, a router may
   process its IPv6 header and any necessary extension headers as if the
   flow label were zero.  That processing would include determining the
   next-hop interface, and possibly other actions, such as updating a
   hop-by-hop option, advancing the pointer and addresses in a Routing
   header, or deciding on how to queue the packet based on its Priority
   field.  The router may then choose to "remember" the results of those
   processing steps and cache that information, using the source address
   plus the flow label as the cache key.  Subsequent packets with the
   same source address and flow label may then be handled by referring
   to the cached information rather than examining all those fields
   that, according to the requirements of the previous paragraph, can be
   assumed unchanged from the first packet seen in the flow.

   Cached flow-handling state that is set up opportunistically, as
   discussed in the preceding paragraph, must be discarded no more than
   6 seconds after it is established, regardless of whether or not
   packets of the same flow continue to arrive.  If another packet with
   the same source address and flow label arrives after the cached state
   has been discarded, the packet undergoes full, normal processing (as
   if its flow label were zero), which may result in the re-creation of
   cached flow state for that flow.