Using the Flow Label Field in IPv6
RFC 1809

Document Type RFC - Informational (June 1995; No errata)
Author Craig Partridge 
Last updated 2013-03-02
Stream Legacy
Formats plain text html pdf htmlized bibtex
Stream Legacy state (None)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state RFC 1809 (Informational)
Telechat date
Responsible AD (None)
Send notices to (None)
Network Working Group                                       C. Partridge
Request for Comments: 1809                  BBN Systems and Technologies
Category: Informational                                        June 1995

                   Using the Flow Label Field in IPv6

Status of this Memo

   This memo provides information for the Internet community.  This memo
   does not specify an Internet standard of any kind.  Distribution of
   this memo is unlimited.


   The purpose of this memo is to distill various opinions and
   suggestions of the End-to-End Research Group regarding the handling
   of Flow Labels into a set of suggestions for IPv6.  This memo is for
   information purposes only and is not one of the IPv6 specifications.
   Distribution of this memo is unlimited.


   This memo originated as the report of a discussion at an End-to-End
   Research Group meeting in November 1994.  At that meeting the group
   discussed several issues regarding how to manage flow identifiers in
   IPv6.   A report of the meeting was then circulated to the IPv6
   community.  Feedback from that community resulted in changes to this
   memo and in changes to the IPv6 specification to fix some minor
   problems the End-to-End Group had raised.

   While many of the ideas in this memo have found their way into the
   IPv6 specification, the explanation of why various design decisions
   were made have not.  This memo is intended to provide some additional
   context for interested parties.

Brief Description of the Flow Label

   The current draft of the IPv6 specification states that every IPv6
   header contains a 24-bit Flow Label.  (Originally the specification
   called for a 28-bit Flow ID field, which included the flow label and
   a 4-bit priority field.  The priority field is now distinct, for
   reasons discussed at the end of this memo).

Partridge                    Informational                      [Page 1]
RFC 1809                                                       June 1995

   The Flow Label is a pseudo-random number between 1 and FFFFFF (hex)
   that is unique when combined with the source address.  The zero Flow
   Label is reserved to say that no Flow Label is being used.  The
   specification requires that a source must not reuse a Flow Label
   value until all state information for the previous use of the Flow
   Label has been flushed from all routers in the internet.

   The specification further requires that all datagrams with the same
   (non-zero) Flow Label must have the same Destination Address, Hop-
   by-Hop Options header, Routing Header and Source Address contents.
   The notion is that by simply looking up the Flow Label in a table,
   the router can decide how to route and forward the datagram without
   examining the rest of the header.

Flow Label Issues

   The IPv6 specification originally left open a number of questions, of
   which these three were among the most important:

        1.   What should a router do if a datagram with a (non-zero)
             Flow Label arrives and the router has no state for that
             Flow Label?

        2.   How does an internet flush old Flow Labels?

        3.   Which datagrams should carry (non-zero) Flow Labels?

   This memo summarizes the End-to-End Group's attempts to answer these

What Does a Router Do With Flow Labels for Which It Has No State?

   If a datagram with a non-zero Flow Label arrives at a router and the
   router discovers it has no state information for that Flow Label,
   what is the correct thing for the router to do?

   The IPv6 specification allows routers to ignore Flow Labels and also
   allows for the possibility that IPv6 datagrams may carry flow setup
   information in their options.  Unknown Flow Labels may also occur if
   a router crashes and loses its state.  During a recovery period, the
   router will receive datagrams with Flow Labels it does not know, but
   this is arguably not an error, but rather a part of the recovery
   period.  Finally, if the controversial suggestion that each TCP
   connection be assigned a separate Flow Label is adopted, it may be
   necessary to manage Flow Labels using an LRU cache (to avoid Flow
   Label cache overflow in routers), in which case an active but
   infrequently used flow's state may have been intentionally discarded.

Partridge                    Informational                      [Page 2]
RFC 1809                                                       June 1995

   In any case, it is clear that treating this situation as an error
   and, say dropping the datagram and sending an ICMP message, is
   inappropriate.  Indeed, it seems likely that in most cases, simply
   forwarding the datagram as one would a datagram with a zero Flow
   Label would give better service to the flow than dropping the

   Of course, there will be situations in which routing the datagram as
   if its Flow Label were zero will cause the wrong result.  An example
Show full document text