[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: (draft-rajahalme-ipv6-flow-label) 00 01 02 03 04 05 06 07 08 09 RFC 3697

IPv6 Working Group                                          J. Rajahalme
INTERNET-DRAFT                                                     Nokia
<draft-ietf-ipv6-flow-label-04.txt>                             A. Conta
                                                            B. Carpenter
                                                              S. Deering
Expires: June 2003                                         December 2002

                     IPv6 Flow Label Specification

Status of this memo

   This document is an Internet-Draft and is subject to all provisions
   of Section 10 of RFC2026.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups. Note that other
   groups may also distribute working documents as Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time. It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at

   The list of Internet-Draft Shadow Directories can be accessed at


   This document specifies the IPv6 Flow Label field, the requirements
   for IPv6 source nodes labeling flows, and the requirements for flow
   state establishment methods.

   The usage of the Flow Label field enables efficient IPv6 flow
   classification based only on IPv6 main header fields in fixed

1.  Introduction

   A flow is a sequence of packets sent from a particular source to a
   particular unicast, anycast or multicast destination that the source
   desires to label as a flow. A flow could consist of all packets in a
   specific transport connection or a media stream. However, a flow is
   not necessarily 1:1 mapped to a transport connection.

Rajahalme, et al.          Expires: June 2003                   [Page 1]

INTERNET-DRAFT     draft-ietf-ipv6-flow-label-04.txt       December 2002

   Traditionally, flow classifiers have been based on the 5-tuple of the
   source and destination addresses, ports 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
   option headers may be inefficient. Additionally, if classifiers
   depend only on IP layer headers, later introduction of alternative
   transport layer protocols will be easier.

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

   The minimum level of IPv6 flow support consists of labeling the
   flows. IPv6 source nodes can label known flows (e.g. TCP connections,
   application streams), even if the node itself would not require any
   flow-specific treatment. Doing this enables load spreading and
   receiver oriented resource reservations, for example. Node
   requirements for flow labeling are given in section 3.

   Specific flow state establishment methods and the related service
   models are out of scope for this specification, but the generic
   requirements enabling co-existence of different methods in IPv6 nodes
   are set forth in section 4.

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   document are to be interpreted as described in RFC 2119 [KEYWORDS].

2.  IPv6 Flow Label Specification

   The 20-bit Flow Label field in the IPv6 header [IPv6] SHOULD be used
   by a source to label packets of a flow. A non-zero Flow Label
   indicates that the IPv6 packet is labeled. IPv6 nodes forwarding or
   receiving a labeled IPv6 packet can use the Flow Label and Source and
   Destination Address fields to classify the packet to a certain flow.
   The packet MAY be given some flow-specific treatment based on the
   flow state established on a set of IPv6 nodes. The nature of the
   specific treatment and the methods for the flow state establishment
   are out of scope for this specification.

   The Flow Label value set by the source MUST be delivered unchanged to
   the destination node(s).

   IPv6 nodes MUST NOT assume any mathematical or other properties of
   the Flow Label values assigned by source nodes. Router performance
   SHOULD NOT be dependent on the distribution of the Flow Label values.
   Especially, the Flow Label bits alone make poor material for a hash

   Nodes keeping dynamic flow state MUST NOT assume packets arriving 60
   seconds or more after the previous packet of a flow still belong to
   the same flow, unless a flow state establishment method in use

Rajahalme, et al.          Expires: June 2003                   [Page 2]

INTERNET-DRAFT     draft-ietf-ipv6-flow-label-04.txt       December 2002

   defines a longer flow state lifetime or the flow state has been
   explicitly refreshed within the lifetime duration.

   If an IPv6 node is not providing flow-specific treatment, it MUST
   ignore the field when receiving or forwarding a packet.

3.  Flow Labeling Requirements

   To enable Flow Label based classification, sources SHOULD assign each
   unrelated transport connection and application data stream to a new
   flow. The source MAY also take part in flow state establishment
   methods that result in assigning certain packets to specific flows. A
   source which does not assign traffic to flows MUST set the Flow Label
   to zero.

   To enable applications and transport protocols to define what packets
   constitute a flow, the source node MUST provide means for the
   applications and transport protocols to specify the Flow Label values
   to be used with their flows. The source node SHOULD be able to select
   unused Flow Label values for flows not requesting a specific value to
   be used.

   A source node MUST keep track of the Flow Label values it is
   currently using or has recently used. Flow Label values previously
   used with a specific pair of source and destination addresses MUST
   NOT be assigned to new flows with the same address pair within 60
   seconds of the termination of the previous flow. If the previous flow
   had a lifetime longer than the default 60 seconds, a quarantine
   period of at least the length of the lifetime MUST be observed.

   The requirement of not reusing a Flow Label value for a new flow with
   the same pair of source and destination addresses extends across
   source node crashes and reboots. To avoid accidental Flow Label value
   reuse, the source node SHOULD use a different initial value for Flow
   Label assignments after a reboot. The initial value could be randomly
   generated, or computed from a previous value stored in non-volatile

4.  Flow State Establishment Requirements

   To enable flow-specific treatment, flow state needs to be established
   on all or a subset of the IPv6 nodes on the path from the source to
   the destination(s). The methods for the state establishment, as well
   as the models for flow-specific treatment will be defined in separate

   To enable co-existence of different methods in IPv6 nodes, the
   methods MUST meet the following basic requirements:

   (1)  The method MUST provide the means for flow state clean-up from
        the IPv6 nodes providing the flow-specific treatment. Signaling

Rajahalme, et al.          Expires: June 2003                   [Page 3]

INTERNET-DRAFT     draft-ietf-ipv6-flow-label-04.txt       December 2002

        based methods where the source node is involved are free to
        specify flow state lifetimes longer than the default 60 seconds.

   (2)  Flow state establishment methods MUST be able to recover from
        the case where the requested flow state cannot be supported.

Security Considerations

   The use of the Flow Label field enables flow classification also in
   the presence of encryption of IPv6 payloads. This allows the
   transport header values to remain confidential, which may lessen the
   possibilities for some forms of traffic analysis. However, the
   labeling of flows defined in this specification may reveal some
   structure of communications otherwise concealed by transport mode


   The discussion on the topic in the IPv6 WG mailing list has been
   instrumental for the definition of this specification. The authors
   want to thank Steve Blake, Jim Bound, Francis Dupont, Robert Elz,
   Tony Hain, Robert Hancock, Bob Hinden, Christian Huitema, Frank
   Kastenholz, Charles Perkins, Hesham Soliman, Michael Thomas, and
   Margaret Wasserman for their contributions.

Normative References

   [IPv6]      Deering, S., Hinden, R., "Internet Protocol Version 6
               Specification", RFC 2460, December 1998.

   [KEYWORDS]  Bradner, S., "Key words for use in RFCs to indicate
               requirement levels", BCP 14, RFC 2119, March 1997.

Authors' Addresses

   Jarno Rajahalme
   Nokia Research Center
   P.O. Box 407
   E-mail: jarno.rajahalme@nokia.com

   Alex Conta
   Transwitch Corporation
   3 Enterprise Drive
   Shelton, CT 06484
   Email: aconta@txc.com

Rajahalme, et al.          Expires: June 2003                   [Page 4]

INTERNET-DRAFT     draft-ietf-ipv6-flow-label-04.txt       December 2002

   Brian E. Carpenter
   IBM Zurich Research Laboratory
   Saeumerstrasse 4 / Postfach
   8803 Rueschlikon
   Email: brian@hursley.ibm.com

   Steve Deering
   Cisco Systems, Inc.
   170 West Tasman Drive
   San Jose, CA 95134-1706
   Email: deering@cisco.com

IPR Notices

   The IETF takes no position regarding the validity or scope of
   any intellectual property or other rights that might be claimed
   to  pertain to the implementation or use of the technology
   described in this document or the extent to which any license
   under such rights might or might not be available; neither does
   it represent that it has made any effort to identify any such
   rights.  Information on the IETF's procedures with respect to
   rights in standards-track and standards-related documentation
   can be found in BCP-11.  Copies of claims of rights made
   available for publication and any assurances of licenses to
   be made available, or the result of an attempt made
   to obtain a general license or permission for the use of such
   proprietary rights by implementors or users of this
   specification can be obtained from the IETF Secretariat.

   The IETF invites any interested party to bring to its
   attention any copyrights, patents or patent applications, or
   other proprietary rights which may cover technology that may be
   required to practice this standard.  Please address the
   information to the IETF Executive Director.

Copyright Notice

   Copyright (C) The Internet Society (date). All Rights

   This document and translations of it may be copied and
   furnished to others, and derivative works that comment on or
   otherwise explain it or assist in its implementation may be
   prepared, copied, published and distributed, in whole or in
   part, without restriction of any kind, provided that the above
   copyright notice and this paragraph are included on all such
   copies and derivative works.  However, this document itself may
   not be modified in any way, such as by removing the copyright
   notice or references to the Internet Society or other Internet

Rajahalme, et al.          Expires: June 2003                   [Page 5]

INTERNET-DRAFT     draft-ietf-ipv6-flow-label-04.txt       December 2002

   organizations, except as needed for the purpose of developing
   Internet standards in which case the procedures for copyrights
   defined in the Internet Standards process must be followed, or
   as required to translate it into languages other than English.

   The limited permissions granted above are perpetual and will
   not be revoked by the Internet Society or its successors or

   This document and the information contained herein is provided

Expiration Date

   This memo is filed as <draft-ietf-ipv6-flow-label-04.txt> and expires
   in June 2003.

Rajahalme, et al.          Expires: June 2003                   [Page 6]

Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/