idnits 2.17.1 draft-donley-6man-flowlabel-transport-sig-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 1, 2010) is 5169 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Outdated reference: A later version (-04) exists of draft-carpenter-6man-flow-update-00 ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 3697 (Obsoleted by RFC 6437) Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group C. Donley 3 Internet-Draft CableLabs 4 Intended status: Experimental K. Erichsen 5 Expires: September 2, 2010 Time Warner Cable 6 March 1, 2010 8 Using the Flow Label for Transport Signaling 9 draft-donley-6man-flowlabel-transport-sig-00 11 Abstract 13 This document extends the use of the IPv6 Flow Label to include 14 transport header and port information. The inclusion of these 15 details allows for the application of Quality of Service (QoS) 16 classification and prioritization, and permits hardware acceleration 17 of IP traffic flows encapsulated within other protocols such as Dual- 18 Stack Lite, Generic Routing Encapsulation (GRE) and Layer 2 Tunneling 19 Protocol version 3 (L2TPv3). 21 Status of this Memo 23 This Internet-Draft is submitted to IETF in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF), its areas, and its working groups. Note that 28 other groups may also distribute working documents as Internet- 29 Drafts. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 The list of current Internet-Drafts can be accessed at 37 http://www.ietf.org/ietf/1id-abstracts.txt. 39 The list of Internet-Draft Shadow Directories can be accessed at 40 http://www.ietf.org/shadow.html. 42 This Internet-Draft will expire on September 2, 2010. 44 Copyright Notice 46 Copyright (c) 2010 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 2. Conventions used in this document . . . . . . . . . . . . . . 5 63 3. Using the IPv6 Flow Label for Transport Signaling . . . . . . 6 64 4. Security Considerations . . . . . . . . . . . . . . . . . . . 8 65 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 66 6. Normative References . . . . . . . . . . . . . . . . . . . . . 10 67 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 11 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 70 1. Introduction 72 As described in [RFC2460], the IP version 6 (IPv6) Main Header may 73 include IPv6 Extension Headers in any order between the IPv6 Main 74 Header and the upper layer protocol header. This poses a problem for 75 some routers, many deep packet inspection (DPI) appliances, and most 76 residential/small office devices such as home gateways. These 77 devices may have difficulty identifying the upper layer transport 78 protocol and/or port number for special handling of the packet in 79 hardware. 81 By providing a pointer to expose the transport header and port number 82 directly within the Main Header, an implementer may more easily 83 support hardware-assisted packet forwarding and prioritization of 84 flows based on transport information. For example, during the 85 transition from IPv4 to IPv6, it is likely that IP traffic will be 86 encapsulated inside of IPv6 at a home gateway, thereby inserting an 87 additional Extension Header and further obscuring transport protocol 88 information from the forwarding engine. The QoS advantage is 89 compounded as additional Extension Headers are added, such as an 90 Encapsulating Security Payload (ESP) header for IPSEC VPNs. The IPv6 91 main header's Flow Label field and its relation to the other fields 92 in the IPv6 header are detailed in Figure 1. 94 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 95 |Version| Traffic Class | Flow Label | 96 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 97 | Payload Length | Next Header | Hop Limit | 98 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 99 | | 100 + + 101 | | 102 + Source Address + 103 | | 104 + + 105 | | 106 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 107 | | 108 + + 109 | | 110 + Destination Address + 111 | | 112 + + 113 | | 114 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 116 Figure 1 IPv6 Main Header 117 As described in [RFC3697], a flow is a sequence of packets sent from 118 a particular source to a particular unicast, anycast, or multicast 119 destination that the source desires to label as a flow. Packet 120 classifiers can use the triplet of Flow Label, Source Address, and 121 Destination Address fields to identify packets belonging to a 122 particular flow. [RFC3697] assumes that Flow Labels uniquely 123 identify a flow and that they do not contain mathematical or other 124 properties; however, as allowed by [I-D.carpenter-6man-flow-update], 125 if protocol and port information are included in the Flow Label, 126 routers can use the Flow Label for hardware-accelerated forwarding 127 and packet classification. 129 2. Conventions used in this document 131 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 132 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 133 document are to be interpreted as described in [RFC2119]. 135 3. Using the IPv6 Flow Label for Transport Signaling 137 The IPv6 Main Header contains a Next Header field that points to the 138 Extended Header following the Main Header, as shown in Figure 1. 139 Each Extended Header that may be present contains its own Next Header 140 field, providing a chain to each Extended Header until the last 141 Extended Header in the sequence is populated with a Next Header value 142 of "no next header". 144 The IPv6 Main Header also contains a Flow Label field that is 145 intended to be used for QoS classification. To enhance Flow Label 146 based classification, encapsulating routers MUST set the most 147 significant bit to 1 to indicate [I-D.carpenter-6man-flow-update] 148 behavior, and SHOULD include the 8-bit IANA-assigned protocol number 149 and the low order 10 bits of the IANA-assigned port number (if 150 applicable) of the unencapsulated IP packet in the Flow Label field 151 of the encapsulating IPv6 header, as shown in Figure 2. Such routers 152 SHOULD set the P bit to 0 to indicate that the port number is the 153 destination port or 1 to indicate that the port number is the source 154 port. 156 Whenever the Next Header field in the IPv6 Main Header does not 157 contain the transport header information (e.g. TCP, UDP), as would 158 be the case when IP in IP encapsulation is configured, the Flow Label 159 will expose the transport protocol and port information directly 160 within the IPv6 Main Header, allowing classification on any router 161 implementing Flow Label handling while providing performance 162 enhancement on most commodity-based routers. 164 Routers along the transmission path can classify traffic based on the 165 Flow Label either in its entirety or by using a wildcard mask to 166 consider only certain bits such as the representation of the 167 transport protocol or port number. 169 1 170 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 171 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 172 |L|Transport Proto|P| Port Number | 173 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 175 Figure 2 IPv6 Flow Label 177 L - Set to 1 to indicate that the flow label follows 178 [I-D.carpenter-6man-flow-update], rather than [RFC3697] behavior. 180 Transport Protocol - 8-bit IANA-defined protocol [IANAProtocol] 182 P - Set to 0 to indicate Destination Port or 1 to indicate Source 183 Port 185 Port Number - the lower 10 bits of the 16-bit IANA-defined port 186 number [IANAPort] (e.g. the modulo(1024) representation of the port 187 number). If the P bit is set to 0, the port number MUST be set to 188 the segment's destination port. If the P bit is set to 1, the port 189 number MUST be set to the segment's source port. If the transport 190 protocol does not use ports, these bits MAY be set to a pseudo-random 191 sequence, as described in [RFC3697]. 193 4. Security Considerations 195 Security considerations are described in [RFC3697], section 5. The 196 flow label is not protected, and could be modified by an on-path 197 attacker. However, the impact of any such modification would be 198 limited to the QoS treatment of the modified packet(s). 200 5. IANA Considerations 202 There are no IANA considerations. 204 6. Normative References 206 [I-D.carpenter-6man-flow-update] 207 Carpenter, B. and S. Jiang, "Update to the IPv6 flow label 208 specification", draft-carpenter-6man-flow-update-00 (work 209 in progress), February 2010. 211 [IANAPort] 212 Internet Assigned Numbers Authority (IANA), "Port Numbers 213 Registry", http://www.iana.org/assignments/port-numbers. 215 [IANAProtocol] 216 Internet Assigned Numbers Authority (IANA), "Protocol 217 Registry", 218 http://www.iana.org/assignments/protocol-numbers. 220 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 221 Requirement Levels", BCP 14, RFC 2119, March 1997. 223 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 224 (IPv6) Specification", RFC 2460, December 1998. 226 [RFC3697] Rajahalme, J., Conta, A., Carpenter, B., and S. Deering, 227 "IPv6 Flow Label Specification", RFC 3697, March 2004. 229 Appendix A. Acknowledgements 231 Thanks to the following people for their guidance and feedback: 233 Lee Howard 235 Andy Shappell 237 Chris Williams 239 Authors' Addresses 241 Chris Donley 242 CableLabs 243 858 Coal Creek Circle 244 Louisville, CO 80027 245 USA 247 Email: c.donley@cablelabs.com 249 Kirk Erichsen 250 Time Warner Cable 251 12101 Airport Way 252 Broomfield, CO 80021 253 USA 255 Email: kirk.erichsen@twcable.com