idnits 2.17.1 draft-ietf-ipv6-flow-label-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 67 has weird spacing: '... method stat...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 2002) is 7979 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'IPv6' is defined on line 284, but no explicit reference was found in the text == Unused Reference: 'Rajahalme' is defined on line 293, but no explicit reference was found in the text == Unused Reference: 'RFC1809' is defined on line 298, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2460 (ref. 'IPv6') (Obsoleted by RFC 8200) -- Obsolete informational reference (is this intentional?): RFC 2327 (ref. 'SDP') (Obsoleted by RFC 4566) Summary: 2 errors (**), 0 flaws (~~), 5 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 IPv6 Working Group J. Rajahalme 2 INTERNET-DRAFT Nokia 3 A. Conta 4 Transwitch 5 B. Carpenter 6 IBM 7 S. Deering 8 Cisco 9 Expires: December 2002 June 2002 11 IPv6 Flow Label Specification 12 draft-ietf-ipv6-flow-label-02.txt 14 Status of this memo 16 This document is an Internet-Draft and is subject to all provisions 17 of Section 10 of RFC2026. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that other 21 groups may also distribute working documents as Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/1id-abstracts.html 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html 34 Abstract 36 This document specifies the usage of the IPv6 Flow Label field, the 37 requirements for IPv6 source nodes labeling flows, and the 38 requirements for flow state establishment methods. 40 1. Terminology and Definitions 42 Classifier An IP layer entity that selects packets based 43 on the content of packet headers according to 44 defined rules. 46 Flow A sequence of related packets sent from a 47 source to a unicast, anycast, or multicast 48 destination(s). A flow could consist of all 49 packets in a specific transport connection, or 50 a media stream. However, a flow is not 51 necessarily 1:1 mapped to a transport 52 connection. 54 This definition should not be confused with 55 the more restrictive definitions for "flow" 56 and "microflow" in [RSVP] and [DiffServ], 57 respectively. This definition includes, but is 58 not limited to them. 60 Flow state The information stored in an IP node driving 61 the flow classification and the flow-specific 62 treatment. The required information is 63 specified by the method defining the flow- 64 specific treatment. 66 Flow state A control mechanism used to set up the flow 67 establishment method state. A flow state establishment method can 68 be either 69 - Dynamic, under source node control (e.g. 70 RSVP), 71 - Quasi-dynamic, under network management 72 control, or 73 - Static, through manual configuration. 74 - Algorithmic (e.g. load-spreading) 76 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 77 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 78 document are to be interpreted as described in RFC 2119. 80 2. Introduction 82 A flow is a sequence of related packets sent from a source to a 83 unicast, anycast, or multicast destination(s). To enable specific 84 processing for the flow, flow state needs to be established on the 85 nodes providing the flow-specific treatment. The flow state defines 86 what kind of treatment should be provided, and how to classify the 87 packets to the flow. 89 Traditionally, flow classifiers have been based on the 5-tuple of the 90 source and destination addresses, ports and the transport protocol 91 type (e.g. the "microflow" definition in [DiffServ]). However, these 92 fields may be unavailable due to either fragmentation or encryption, 93 or locating them past a chain of IPv6 option headers may be 94 inefficient. Additionally, dependence on higher layer headers by the 95 IP layer represents a layer violation, possibly hindering the 96 introduction of new transport protocols. 98 The 3-tuple of the Flow Label and the Source and Destination Address 99 fields enables efficient IPv6 flow classification, where only IPv6 100 main header fields in fixed positions are used. The specification of 101 the IPv6 Flow Label field is given in section 3 below. 103 The minimum level of IPv6 flow support consists of labeling the 104 flows. IPv6 source nodes can label known flows (e.g. TCP connections, 105 RTP streams), even if the node itself would not require any flow- 106 specific treatment. Doing this enables receiver oriented resource 107 reservations, e.g. [RSVP]. Requirements for flow labeling are given 108 in section 4. 110 Specific flow state establishment methods and the related service 111 models are out of scope for this specification, but the generic 112 requirements enabling co-existence of different methods in IPv6 nodes 113 are set forth in section 5. 115 3. IPv6 Flow Label Specification 117 The 20-bit Flow Label field in the IPv6 header SHOULD be used by a 118 source to label sequences of related packets sent to a specific 119 unicast, anycast, or multicast destination(s). A non-zero Flow Label 120 indicates that the IPv6 packet is labeled. IPv6 nodes receiving a 121 labeled IPv6 packet can use the Flow Label, and Source and 122 Destination Address fields to classify the packet to a certain flow. 123 The packet MAY be given some flow-specific treatment based on the 124 flow state established on a set of IPv6 nodes. The nature of the 125 specific treatment and the methods for the flow state establishment 126 are out of scope for this specification. 128 The Flow Label value set by the source MUST be delivered unchanged to 129 the destination(s). 131 IPv6 nodes MUST NOT assume mathematical or other non-standardized 132 properties of the Flow Label values assigned by source nodes. Router 133 performance SHOULD NOT be dependent on the distribution of the Flow 134 Label values. Especially, the Flow Label bits alone make poor 135 material for a hash key. 137 If an IPv6 node is not providing flow-specific treatment, it MUST 138 ignore the field when receiving or forwarding a packet. 140 4. Flow Labeling Requirements 142 To enable Flow Label based classification, the source MUST label all 143 packets belonging to a flow with the Flow Label value assigned to the 144 flow. 146 The assignment of a packet to a flow takes various forms, presented 147 below: 149 (1) The source MAY take part in a signaling protocol that results in 150 assigning certain transport connection(s) or application data 151 stream(s) to specific flow(s). 153 (2) The source MAY be configured to assign certain transport 154 connection(s) or application data stream(s) to specific flow(s). 156 (3) The source SHOULD assign each new application data stream (e.g. 157 RTP streams) to a new flow. 159 (4) The source SHOULD assign each new transport connection (e.g. 160 TCP, SCTP) to a new flow. 162 It is necessary that flow classifiers downstream from the source can 163 classify packets unambiguously, i.e. that all packets which the 164 source has chosen to label as a single flow can be efficiently 165 identified as such. 167 To enable this, the source node MUST keep track of the Flow Label 168 values it is currently using or has recently used. When a new flow is 169 instantiated, a unique Flow Label MUST be assigned to it. A Flow 170 Label value is considered unique if it is not currently in use with 171 the same Source and Destination addresses. In the case of flows with 172 multiple addresses (e.g., SCTP flows) this requirement for uniqueness 173 extends to all possible (Source, Destination) address pairs. 175 The IPv6 source node MUST provide a facility for verifying and 176 assigning new Flow Label values, and for storing the Flow Label, and 177 the associated Source and Destination Addresses currently in use. The 178 facility MUST be used whenever a label needs to be assigned for a new 179 flow. The facility SHOULD provide a programming interface with at 180 least the following functionality: 182 (1) to assign any Flow Label value for a new flow 184 (2) to assign a specific Flow Label for a new flow, and 186 (3) to delete a flow, i.e. to free a Flow Label no longer in use. 188 The interface definition for the facility is beyond the scope of this 189 document. 191 When a dynamically instantiated flow terminates, its Flow Label value 192 MUST NOT be reused until it is certain that all associated state has 193 been deleted from all nodes on the path. With some flow state 194 establishment methods signaling new state may be sufficient. A 195 mechanism with a sufficiently long timeout period before reusing the 196 Flow Label values can also be used. 198 With [RSVP] or [SDP] either the source or the destination of the flow 199 could have a preference for the Flow Label value to be used. For 200 example, a destination with multiple sources sending packets to it 201 could require all the sources to use the same Flow Label value in 202 order to collapse the classifier state to a single flow state entry, 203 instead of having separate classifier state for each source (ref. the 204 Wildcard-Filter reservation style in [RSVP]). Therefore the source 205 SHOULD honor the destination's request to mark the packets with the 206 Flow Label value specified. 208 To enable the peer(s) to know the assigned or requested Flow Label 209 value, the value SHOULD be included along with the Source and 210 Destination addresses as part of any signaling dealing with the flow, 211 e.g. transport layer connection set up, RSVP for resource 212 reservation, or SDP for media session parameters. 214 5. Flow State Establishment Requirements 216 To enable flow-specific treatment, flow state needs to be established 217 on all or a subset of the IPv6 nodes on the path from the source to 218 the destination(s). The methods for the state establishment, as well 219 as the models for flow-specific treatment are defined in separate 220 specifications. 222 To enable co-existence of different methods in IPv6 nodes, the 223 methods MUST meet the following basic requirements: 225 (1) A packet is classified unambiguously to a flow on the basis of 226 the Flow Label, and the Source and Destination Address fields. 227 Depending on the method semantics, multiple such triplets MAY 228 identify the same flow state (e.g. SCTP flows with multiple 229 addresses at either end-points, or a diffserv classifier with an 230 address range. See also the RSVP Wildcard-Filter example in 231 section 4 above). The flow state establishment method MUST 232 convey this classifying information to the IPv6 nodes that need 233 to perform the classification. Usage of any additional header 234 fields for flow classification is beyond the scope of this 235 specification. 237 (2) The IPv6 node facility keeping track of the Flow Label, and the 238 associated Source and Destination Addresses MUST be utilized 239 when assigning Flow Label values to new flows (see section 4 240 above). 242 (3) The Flow Label value 0 is reserved for non-labeled packets. 244 (4) The method MUST provide the means for flow state clean-up from 245 the IPv6 nodes providing the flow-specific treatment. Both soft- 246 and hard-state methods are possible. 248 (5) Flow state establishment methods SHOULD be able to recover from 249 the case where the requested flow state cannot be supported. 251 (6) Flow state establishment methods SHOULD include the Mobile IP 252 Home Addresses of the source and the destination in the state 253 establishment process in addition to the Care-of Addresses, if 254 available. This enables avoiding state duplication on fixed 255 portions of the path when either end changes its Care-of 256 Address. 258 Security Considerations 260 Anything that facilitates flow classification also increases the 261 vulnerability to traffic analysis. 263 The use of the Flow Label field in general enables flow 264 classification also in the presence of ESP encryption of IPv6 265 payloads. This allows the transport header values to remain 266 confidential, which may lessen the possibilities for some forms of 267 traffic analysis. 269 IANA Considerations 271 This specification does not define any well-known values. 273 Acknowledgements 275 The discussion on the topic in the IPv6 WG mailing list has been 276 instrumental for the definition of this specification. The authors 277 want to thank Steve Blake, Jim Bound, Francis Dupont, Robert Elz, 278 Tony Hain, Bob Hinden, Christian Huitema, Frank Kastenholz, Charles 279 Perkins, Hesham Soliman, Michael Thomas, and Margaret Wasserman for 280 their contributions. 282 Normative References 284 [IPv6] S. Deering, R. Hinden, "Internet Protocol Version 6 285 Specification", RFC 2460, December 1998. 287 Informative References 289 [DiffServ] S. Blake, D. Black, M. Carlson, E. Davies, Z. Wang, W. 290 Weiss, "An Architecture for Differentiated Service", RFC 291 2475, December 1998. 293 [Rajahalme] J. Rajahalme, A. Conta, "An IPv6 Flow Label Specification 294 Proposal", Internet Draft , November 2001, expires May 2002, Work in 296 progress. 298 [RFC1809] C. Partridge, "Using the Flow Label Field in IPv6", RFC 299 1809, June 1995. 301 [RSVP] R. Braden, L. Zhang, S. Berson, S. Herzog, S. Jamin, 302 "Resource Reservation Protocol (RSVP) Version 1 303 Functional Specification", RFC 2205, September 1997. 305 [SDP] M. Handley, V. Jacobson, "SDP: Session Description 306 Protocol", RFC 2327, April 1998. 308 Authors' Addresses 310 Jarno Rajahalme 311 Nokia Research Center 312 P.O. Box 407 313 FIN-00045 NOKIA GROUP, 314 Finland 315 E-mail: jarno.rajahalme@nokia.com 317 Alex Conta 318 Transwitch Corporation 319 3 Enterprise Drive 320 Shelton, CT 06484 321 USA 322 Email: aconta@txc.com 324 Brian E. Carpenter 325 IBM Zurich Research Laboratory 326 Saeumerstrasse 4 / Postfach 327 8803 Rueschlikon 328 Switzerland 329 Email: brian@hursley.ibm.com 331 Steve Deering 332 Cisco Systems, Inc. 333 170 West Tasman Drive 334 San Jose, CA 95134-1706 335 USA 336 Email: deering@cisco.com 338 Expiration Date 340 This memo is filed as and expires 341 in December 2002.