Network Working Group C. Donley Internet-Draft CableLabs Intended status: Experimental K. Erichsen Expires: September 2, 2010 Time Warner Cable March 1, 2010 Using the Flow Label for Transport Signaling draft-donley-6man-flowlabel-transport-sig-00 Abstract This document extends the use of the IPv6 Flow Label to include transport header and port information. The inclusion of these details allows for the application of Quality of Service (QoS) classification and prioritization, and permits hardware acceleration of IP traffic flows encapsulated within other protocols such as Dual- Stack Lite, Generic Routing Encapsulation (GRE) and Layer 2 Tunneling Protocol version 3 (L2TPv3). Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. 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/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on September 2, 2010. Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. Donley & Erichsen Expires September 2, 2010 [Page 1] Internet-Draft flowlabel-transport-sig March 2010 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions used in this document . . . . . . . . . . . . . . 5 3. Using the IPv6 Flow Label for Transport Signaling . . . . . . 6 4. Security Considerations . . . . . . . . . . . . . . . . . . . 8 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 6. Normative References . . . . . . . . . . . . . . . . . . . . . 10 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 Donley & Erichsen Expires September 2, 2010 [Page 2] Internet-Draft flowlabel-transport-sig March 2010 1. Introduction As described in [RFC2460], the IP version 6 (IPv6) Main Header may include IPv6 Extension Headers in any order between the IPv6 Main Header and the upper layer protocol header. This poses a problem for some routers, many deep packet inspection (DPI) appliances, and most residential/small office devices such as home gateways. These devices may have difficulty identifying the upper layer transport protocol and/or port number for special handling of the packet in hardware. By providing a pointer to expose the transport header and port number directly within the Main Header, an implementer may more easily support hardware-assisted packet forwarding and prioritization of flows based on transport information. For example, during the transition from IPv4 to IPv6, it is likely that IP traffic will be encapsulated inside of IPv6 at a home gateway, thereby inserting an additional Extension Header and further obscuring transport protocol information from the forwarding engine. The QoS advantage is compounded as additional Extension Headers are added, such as an Encapsulating Security Payload (ESP) header for IPSEC VPNs. The IPv6 main header's Flow Label field and its relation to the other fields in the IPv6 header are detailed in Figure 1. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version| Traffic Class | Flow Label | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Payload Length | Next Header | Hop Limit | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Source Address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Destination Address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1 IPv6 Main Header Donley & Erichsen Expires September 2, 2010 [Page 3] Internet-Draft flowlabel-transport-sig March 2010 As described in [RFC3697], 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. Packet classifiers can use the triplet of Flow Label, Source Address, and Destination Address fields to identify packets belonging to a particular flow. [RFC3697] assumes that Flow Labels uniquely identify a flow and that they do not contain mathematical or other properties; however, as allowed by [I-D.carpenter-6man-flow-update], if protocol and port information are included in the Flow Label, routers can use the Flow Label for hardware-accelerated forwarding and packet classification. Donley & Erichsen Expires September 2, 2010 [Page 4] Internet-Draft flowlabel-transport-sig March 2010 2. Conventions used in this document 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 [RFC2119]. Donley & Erichsen Expires September 2, 2010 [Page 5] Internet-Draft flowlabel-transport-sig March 2010 3. Using the IPv6 Flow Label for Transport Signaling The IPv6 Main Header contains a Next Header field that points to the Extended Header following the Main Header, as shown in Figure 1. Each Extended Header that may be present contains its own Next Header field, providing a chain to each Extended Header until the last Extended Header in the sequence is populated with a Next Header value of "no next header". The IPv6 Main Header also contains a Flow Label field that is intended to be used for QoS classification. To enhance Flow Label based classification, encapsulating routers MUST set the most significant bit to 1 to indicate [I-D.carpenter-6man-flow-update] behavior, and SHOULD include the 8-bit IANA-assigned protocol number and the low order 10 bits of the IANA-assigned port number (if applicable) of the unencapsulated IP packet in the Flow Label field of the encapsulating IPv6 header, as shown in Figure 2. Such routers SHOULD set the P bit to 0 to indicate that the port number is the destination port or 1 to indicate that the port number is the source port. Whenever the Next Header field in the IPv6 Main Header does not contain the transport header information (e.g. TCP, UDP), as would be the case when IP in IP encapsulation is configured, the Flow Label will expose the transport protocol and port information directly within the IPv6 Main Header, allowing classification on any router implementing Flow Label handling while providing performance enhancement on most commodity-based routers. Routers along the transmission path can classify traffic based on the Flow Label either in its entirety or by using a wildcard mask to consider only certain bits such as the representation of the transport protocol or port number. 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |L|Transport Proto|P| Port Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2 IPv6 Flow Label L - Set to 1 to indicate that the flow label follows [I-D.carpenter-6man-flow-update], rather than [RFC3697] behavior. Transport Protocol - 8-bit IANA-defined protocol [IANAProtocol] P - Set to 0 to indicate Destination Port or 1 to indicate Source Donley & Erichsen Expires September 2, 2010 [Page 6] Internet-Draft flowlabel-transport-sig March 2010 Port Port Number - the lower 10 bits of the 16-bit IANA-defined port number [IANAPort] (e.g. the modulo(1024) representation of the port number). If the P bit is set to 0, the port number MUST be set to the segment's destination port. If the P bit is set to 1, the port number MUST be set to the segment's source port. If the transport protocol does not use ports, these bits MAY be set to a pseudo-random sequence, as described in [RFC3697]. Donley & Erichsen Expires September 2, 2010 [Page 7] Internet-Draft flowlabel-transport-sig March 2010 4. Security Considerations Security considerations are described in [RFC3697], section 5. The flow label is not protected, and could be modified by an on-path attacker. However, the impact of any such modification would be limited to the QoS treatment of the modified packet(s). Donley & Erichsen Expires September 2, 2010 [Page 8] Internet-Draft flowlabel-transport-sig March 2010 5. IANA Considerations There are no IANA considerations. Donley & Erichsen Expires September 2, 2010 [Page 9] Internet-Draft flowlabel-transport-sig March 2010 6. Normative References [I-D.carpenter-6man-flow-update] Carpenter, B. and S. Jiang, "Update to the IPv6 flow label specification", draft-carpenter-6man-flow-update-00 (work in progress), February 2010. [IANAPort] Internet Assigned Numbers Authority (IANA), "Port Numbers Registry", http://www.iana.org/assignments/port-numbers. [IANAProtocol] Internet Assigned Numbers Authority (IANA), "Protocol Registry", http://www.iana.org/assignments/protocol-numbers. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. [RFC3697] Rajahalme, J., Conta, A., Carpenter, B., and S. Deering, "IPv6 Flow Label Specification", RFC 3697, March 2004. Donley & Erichsen Expires September 2, 2010 [Page 10] Internet-Draft flowlabel-transport-sig March 2010 Appendix A. Acknowledgements Thanks to the following people for their guidance and feedback: Lee Howard Andy Shappell Chris Williams Donley & Erichsen Expires September 2, 2010 [Page 11] Internet-Draft flowlabel-transport-sig March 2010 Authors' Addresses Chris Donley CableLabs 858 Coal Creek Circle Louisville, CO 80027 USA Email: c.donley@cablelabs.com Kirk Erichsen Time Warner Cable 12101 Airport Way Broomfield, CO 80021 USA Email: kirk.erichsen@twcable.com Donley & Erichsen Expires September 2, 2010 [Page 12]