IPv6 Working Group J. Rajahalme INTERNET-DRAFT Nokia A. Conta Transwitch B. Carpenter IBM S. Deering Cisco Expires: June 2003 December 2002 IPv6 Flow Label Specification draft-ietf-ipv6-flow-label-04.txt 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 http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Abstract 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 positions. 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", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 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 key. 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 memory. 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 specifications. 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 ESP. Acknowledgements 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 FIN-00045 NOKIA GROUP, Finland E-mail: jarno.rajahalme@nokia.com Alex Conta Transwitch Corporation 3 Enterprise Drive Shelton, CT 06484 USA 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 Switzerland Email: brian@hursley.ibm.com Steve Deering Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134-1706 USA 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 Reserved. 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 assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." Expiration Date This memo is filed as and expires in June 2003. Rajahalme, et al. Expires: June 2003 [Page 6]