The lifetime of flow-handling state that is set up explicitly, for
   example by a control protocol or a hop-by-hop option, must be
   specified as part of the specification of the explicit set-up
   mechanism; it may exceed 6 seconds.

   A source must not re-use a flow label for a new flow within the
   lifetime of any flow-handling state that might have been established
   for the prior use of that flow label.  Since flow-handling state with
   a lifetime of 6 seconds may be established opportunistically for any
   flow, the minimum interval between the last packet of one flow and
   the first packet of a new flow using the same flow label is 6
   seconds.  Flow labels used for explicitly set-up flows with longer
   flow-state lifetimes must remain unused for those longer lifetimes
   before being re-used for new flows.

   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 (at least 6 seconds; more if explicit



 
RFC 1883                   IPv6 Specification              December 1995


   flow set-up mechanisms with longer lifetimes might have been used).
   If the minimum time for rebooting the node is known (often more than
   6 seconds), 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
   performance would be adequate only if most packets belonged to flows,
   or to design a header compression scheme that only worked on packets
   that belonged to flows.


7.  Priority

   The 4-bit Priority field in the IPv6 header enables a source to
   identify the desired delivery priority of its packets, relative to
   other packets from the same source.  The Priority values are divided
   into two ranges:  Values 0 through 7 are used to specify the priority
   of traffic for which the source is providing congestion control,
   i.e., traffic that "backs off" in response to congestion, such as TCP
   traffic.  Values 8 through 15 are used to specify the priority of
   traffic that does not back off in response to congestion, e.g.,
   "real-time" packets being sent at a constant rate.

   For congestion-controlled traffic, the following Priority values are
   recommended for particular application categories:

         0 - uncharacterized traffic
         1 - "filler" traffic (e.g., netnews)
         2 - unattended data transfer (e.g., email)
         3 - (reserved)
         4 - attended bulk transfer (e.g., FTP, NFS)
         5 - (reserved)
         6 - interactive traffic (e.g., telnet, X)
         7 - internet control traffic (e.g., routing protocols, SNMP)

   For non-congestion-controlled traffic, the lowest Priority value (8)
   should be used for those packets that the sender is most willing to
   have discarded under conditions of congestion (e.g., high-fidelity
   video traffic), and the highest value (15) should be used for those
   packets that the sender is least willing to have discarded (e.g.,
   low-fidelity audio traffic).  There is no relative ordering implied
   between the congestion-controlled priorities and the non-congestion-
   controlled priorities.






 
RFC 1883                   IPv6 Specification              December 1995


8. Upper-Layer Protocol Issues

8.1 Upper-Layer Checksums

   Any transport or other upper-layer protocol that includes the
   addresses from the IP header in its checksum computation must be
   modified for use over IPv6, to include the 128-bit IPv6 addresses
   instead of 32-bit IPv4 addresses.  In particular, the following
   illustration shows the TCP and UDP "pseudo-header" for IPv6:

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                                                               +
   |                                                               |