and Routing header from the received packet have been verified
         by the responder.
























 
RFC 2460                   IPv6 Specification              December 1998


Appendix A. Semantics and Usage of the Flow Label Field

   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 FFFFF 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, 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).

   The maximum lifetime of any flow-handling state established along a
   flow's path must be specified as part of the description of the
   state-establishment mechanism, e.g., the resource reservation
   protocol or the flow-setup hop-by-hop option.  A source must not re-
   use a flow label for a new flow within the maximum lifetime of any
   flow-handling state that might have been established for the prior
   use of that flow label.







 
RFC 2460                   IPv6 Specification              December 1998


   When a node stops and restarts (e.g., as a result of a "crash"), it
   must be careful not to use a flow label that it might have used for
   an earlier flow whose lifetime may not have expired yet.  This may be
   accomplished by recording flow label usage on stable storage so that
   it can be remembered across crashes, or by refraining from using any
   flow labels until the maximum lifetime of any possible previously
   established flows has expired.  If the minimum time for rebooting the
   node is known, that time can be deducted from the necessary waiting
   period before starting to allocate flow labels.

   There is no requirement that all, or even most, packets belong to
   flows, i.e., carry non-zero flow labels.  This observation is placed
   here to remind protocol designers and implementors not to assume
   otherwise.  For example, it would be unwise to design a router whose