idnits 2.17.1 draft-hu-flow-label-cases-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 201: '...s that "IPv6 nodes MUST NOT assume any...' RFC 2119 keyword, line 211: '... The standard [RFC3697] also states "Router performance SHOULD NOT be...' RFC 2119 keyword, line 551: '... 2. "Nodes MUST NOT assume any math...' RFC 2119 keyword, line 553: '...uter performance SHOULD NOT be depende...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 690 has weird spacing: '...ding An effic...' -- The document date (February 23, 2011) is 4782 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-02) exists of draft-donley-softwire-dslite-flowlabel-01 == Outdated reference: A later version (-05) exists of draft-ietf-6man-flow-ecmp-01 == Outdated reference: A later version (-07) exists of draft-ietf-6man-flow-update-02 == Outdated reference: A later version (-19) exists of draft-ietf-roll-rpl-18 -- Obsolete informational reference (is this intentional?): RFC 1883 (Obsoleted by RFC 2460) -- Obsolete informational reference (is this intentional?): RFC 2460 (Obsoleted by RFC 8200) -- Obsolete informational reference (is this intentional?): RFC 2629 (Obsoleted by RFC 7749) -- Obsolete informational reference (is this intentional?): RFC 3697 (Obsoleted by RFC 6437) == Outdated reference: A later version (-19) exists of draft-ietf-roll-rpl-07 -- Duplicate reference: draft-ietf-roll-rpl, mentioned in 'RPL-07', was also mentioned in 'I-D.ietf-roll-rpl'. Summary: 1 error (**), 0 flaws (~~), 7 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Independent Submission Q. Hu 3 Internet-Draft B. Carpenter 4 Intended status: Informational Univ. of Auckland 5 Expires: August 27, 2011 February 23, 2011 7 Survey of proposed use cases for the IPv6 flow label 8 draft-hu-flow-label-cases-03 10 Abstract 12 The IPv6 protocol includes a flow label in every packet header, but 13 this field is not used in practice. This paper describes the flow 14 label standard and discusses the implementation issues that it 15 raises. It then describes various published proposals for using the 16 flow label, and shows that most of them are inconsistent with the 17 standard. Methods to address this problem are briefly reviewed. We 18 also question whether the standard should be revised. 20 Status of this Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on August 27, 2011. 37 Copyright Notice 39 Copyright (c) 2011 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 1.1. A brief history of the flow label . . . . . . . . . . . . 3 56 1.2. The flow label and quality of service . . . . . . . . . . 4 57 2. Flow label definition and issues . . . . . . . . . . . . . . . 4 58 2.1. Flow label properties . . . . . . . . . . . . . . . . . . 4 59 2.2. Dependency prohibition . . . . . . . . . . . . . . . . . . 5 60 2.3. Other issues . . . . . . . . . . . . . . . . . . . . . . . 6 61 3. Documented proposals for the flow label . . . . . . . . . . . 7 62 3.1. Specify the flow label as a pseudo-random value . . . . . 7 63 3.1.1. End-to-End QoS Provisioning . . . . . . . . . . . . . 7 64 3.1.2. Load balancing . . . . . . . . . . . . . . . . . . . . 8 65 3.1.3. Security nonce . . . . . . . . . . . . . . . . . . . . 8 66 3.2. Specify QoS parameters in the flow label . . . . . . . . . 9 67 3.3. Use flow label hop-by-hop to control switching . . . . . . 10 68 3.4. Diffserv use of IPv6 flow label . . . . . . . . . . . . . 12 69 3.5. Other uses . . . . . . . . . . . . . . . . . . . . . . . . 12 70 4. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 13 71 5. Security Considerations . . . . . . . . . . . . . . . . . . . 14 72 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 73 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 74 8. Change log . . . . . . . . . . . . . . . . . . . . . . . . . . 15 75 9. Informative References . . . . . . . . . . . . . . . . . . . . 15 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 78 1. Introduction 80 IPv6 is being introduced to overcome the address shortage of the 81 current IPv4 protocol, but it also offers a new feature, i.e., the 82 flow label field in the IPv6 packet header. The flow label is not 83 encrypted by IPsec, and is present in all fragments. However, it is 84 very little used in practice, for reasons discussed below and in 85 [I-D.ietf-6man-flow-update]. After a short introduction, this 86 document summarizes the current specification of the IPv6 flow label 87 and some open issues about its use in Section 2, and then Section 3 88 describes and analyses various proposals that have been made for its 89 use. Finally, Section 4 discusses the implications and attempts to 90 draw conclusions. 92 The flow label field occupies bits 12 through 31 of the IPv6 packet 93 header. It provides a potential way to mark a packet, identify a 94 flow, and look up the corresponding flow state. This field is always 95 present in an IPv6 header, so a phrase such as "a packet with no flow 96 label" refers to a packet whose flow label field contains 20 zero 97 bits, i.e., a flow label whose value is zero. 99 1.1. A brief history of the flow label 101 The original proposal for a flow label has been attributed to Dave 102 Clark [Deering93], who proposed that it should contain a pseudo- 103 random value. A flow label field was included in the packet header 104 during the preliminary design of IPv6, which followed an intense 105 period of debate about several competing proposals. The final choice 106 was made in 1994 [RFC1752]. In particular, the IETF rejected a 107 proposal known as CATNIP [RFC1707], which included so-called 'cache 108 handles' to identify the next hop in high performance routers. Thus 109 CATNIP introduced the notion of a header field that would be shared 110 by all packets belonging to a flow, to control packet forwarding on a 111 hop-by-hop basis. We recognize this today as a precursor of the MPLS 112 label [RFC3031]. 114 The IETF decided instead to develop a proposal known as SIPP into IP 115 version 6. SIPP included "labeling of packets belonging to 116 particular traffic 'flows' for which the sender requests special 117 handling, such as non-default quality of service or 'real-time' 118 service" [RFC1710]. In 1994, this used a 28-bit flow label field. 119 In 1995 it was down to 24 bits [RFC1883] and it was finally reduced 120 to 20 bits [RFC2460] to accommodate the IPv6 Traffic Class, which is 121 fully compatible with the IPv4 Type of Service byte. 123 There was considerable debate in the IETF about the very purpose of 124 the flow label. Was it to be a handle for fast switching, as in 125 CATNIP, or was it to be meaningful to applications and used to 126 specify quality of service? Must it be set by the sending host, or 127 could it be set by routers? Could it be modified en route, or must 128 it be delivered with no change? 130 Because of these uncertainties, and more urgent work, the flow label 131 was consistently ignored by implementors, and today is set to zero in 132 almost every IPv6 packet. In fact, [RFC2460] defined it as 133 "experimental and subject to change." There was considerable 134 preliminary work such as [Metzler00], [Conta01a], 135 [I-D.conta-diffserv-ipv6-fl-classifier] and [Hagino01]. The ensuing 136 proposed standard "IPv6 Flow Label Specification" (RFC 3697) 137 [RFC3697] intended to clarify this situation by providing precise 138 boundary conditions for use of the flow label. However, this has not 139 proved successful in promoting use of the flow label in practice, as 140 a result of which 20 bits are unused in every IPv6 packet header. 142 1.2. The flow label and quality of service 144 Developments in high speed switch design, and the success of MPLS, 145 have largely obviated consideration of the flow label for high-speed 146 switching. Thus, although various use cases for the flow label have 147 been proposed, most of them assume that it should be used principally 148 to support the provision of quality of service (QoS). For many years 149 it has been recognized that real-time Internet traffic requires a 150 different QoS from general data traffic, and this remains true in the 151 era of network neutrality. Thus an alternative to uniform best- 152 effort service is needed, requiring packets to be classified as 153 belonging to a particular class of service or flow. Currently, this 154 leads to a layer violation problem, since a 5-tuple is often used to 155 classify each packet. The 5-tuple includes source and destination 156 addresses, port numbers, and the transport protocol type, so when we 157 want to forward or process packets, we need to extract information 158 from the layer above IP. This may be impossible when packets are 159 encrypted such that port numbers are hidden, or when packets are 160 fragmented, so the layer violation is not an academic concern. The 161 flow label, being exempt from IPsec encryption and being replicated 162 in packet fragments, avoids this difficulty. It has therefore 163 attracted attention from the designers of new approaches to QoS. 165 2. Flow label definition and issues 167 2.1. Flow label properties 169 RFC 3697 [RFC3697] standardizes properties of the flow label, 170 including: 172 o If the packets are not part of any flow, the flow label value is 173 zero. 174 o The 3-tuple {source address, destination address, flow label} 175 uniquely identifies which packets belong to which particular flow. 176 o Packets can receive flow-specific treatment if the node has been 177 set up with flow-specific state. 178 o The flow label set by the source node must be delivered to the 179 destination node, i.e., it is an end-to-end label. 180 o The same pair of source and destination addresses must not use the 181 same flow label value again within a timeout of at least 120 182 seconds. 184 One effect of the second of these rules is to avoid the layer 185 violation problem mentioned in Section 1. By using the 3-tuple, we 186 only use the IP layer to classify packets, without needing any 187 transport layer information. This may reduce the lookup time if 188 flow-based treatment is required, and will work even with IPsec 189 encryption and fragmentation. Therefore, for traffic needing other 190 than best-effort service, such as real-time applications, the flow 191 label can be set to different values to represent different flows, 192 and each node forwarding or receiving the packets may provide 193 different flow-specific treatments by looking at the flow label 194 value. This is more fine-grained than differentiated services 195 (Diffserv) [Carpenter02], [RFC2474] but need not be less efficient. 197 2.2. Dependency prohibition 199 An additional important rule in the standard [RFC3697] effectively 200 forbids any encoding of meaning in the bits of the flow label. To be 201 exact, the standard states that "IPv6 nodes MUST NOT assume any 202 mathematical or other properties of the flow Label values assigned by 203 source nodes." This rule is aimed at the case where a packet from a 204 source using a particular encoding scheme for the flow label reaches 205 a node that is using a different scheme. If by chance the bit 206 pattern in the flow label is meaningful in both schemes, the receiver 207 would misinterpret the flow label. Therefore, in the absence of 208 other information, the receiver must not assume anything about the 209 meaning of the value of the flow label. 211 The standard [RFC3697] also states "Router performance SHOULD NOT be 212 dependent on the distribution of the Flow Label values. Especially, 213 the Flow Label bits alone make poor material for a hash key." The 214 problem this rule is intended to avoid is that if a source uses one 215 method of choosing flow labels (e.g., counting up from 1), any router 216 that assumes another method (e.g., pseudo-randomness) may not perform 217 as intended. 219 Note that there is no easy escape from the combination of these two 220 prohibitions, which we will call the dependency prohibition. Unlike 221 Diffserv code points, flow labels are not locally significant within 222 a single administrative domain; they must be preserved end-to-end. 223 In general, a router cannot know whether a particular packet 224 originated in a host supporting a specific usage of the flow label. 225 Therefore, any method that breaks one or both of these rules will 226 only work if there is some way for a router to determine which 227 sources use the same scheme as itself. 229 The interpretation of the dependency rule can be subtle and is not 230 spelled out in [RFC3697]. A node must not assume properties of the 231 flow label - but it may know them by construction or by signaling. 232 The bits of the flow label alone are poor material for a hash key - 233 but they may be combined with bits from other sources, to provide 234 uniformly distributed hash outputs. 236 2.3. Other issues 238 [RFC3697] does not discuss how to use flow label most effectively. 239 This remains the major open issue, but some authors propose that the 240 label should be used with reserved bandwidth to achieve customized 241 QoS provision. Coupled with admission control at the edge router, 242 this could limit congestion. However, as we will see below, this is 243 not the only proposed use. 245 We now introduce some other open issues. 246 o Unknown flow labels: [RFC1809] proposed that when a router 247 receives a datagram with an unknown flow label, it should treat it 248 as zero. However, the standard [RFC3697] is silent on this issue. 249 Indeed, some methods of flow state establishment might choose to 250 use an unknown label as the trigger for creating flow state. 251 o Deleting old flow labels: When a flow finishes, how does the 252 router know the flow label has expired? Should this be based on a 253 timeout, on observation of the transport layer, or on explicit 254 signalling? [RFC3697] defines a timeout (120 seconds) that 255 effectively imposes a maximum lifetime on flow label state in a 256 router. This implies that flow labeling is inappropriate for very 257 intermittent flows, unless there is some mechanism to refresh 258 router state. In contrast, [I-D.banerjee-flowlabel-ipv6-qos] 259 suggested that a router should send an ICMP message to the source 260 prior to deleting a particular label. The source node may then 261 send a KEEPALIVE message to the router; if it does not, the router 262 will release that label. 263 o Choosing when to set the flow label: For what kinds of application 264 should we set up non-zero flow labels? [RFC1809] suggested not 265 setting it for short flows containing few bytes, but using it for 266 long TCP connections and some real-time applications. 268 o Can we modify the flow label? [RFC3697] states that the flow 269 label must be delivered unchanged. There are several advantages 270 of immutable flow labels, apart from respecting the standard: the 271 rule is easy to understand, does not require extra processing in 272 routers or a signalling protocol, and allows for very simple host 273 implementations. Also, it is straightforward for hosts and 274 routers to simply ignore the flow label. However, this rule does 275 appear to exclude any MPLS-like or CATNIP-like use for optimized 276 packet switching. Some of the proposed mechanisms described below 277 contradict this by suggesting that switches should change the flow 278 label for routing purposes. 280 3. Documented proposals for the flow label 282 In the following, we do not intend to recommend or criticise various 283 proposals. This section shows the variety of proposals that have 284 been published, and whether they are compatible with the existing 285 standard. These proposals almost all assume that the flow label's 286 main purpose is to support QoS, and their flow label mechanisms are 287 entangled with QoS mechanisms. We describe the proposals in five 288 broad, and somewhat overlapping, categories, i.e., 289 1. use pseudo-random flow label values for various purposes (for 290 example, to improve routing performance when retrieving cached 291 routing state) 292 2. define specific QoS requirements as parameters embedded in the 293 flow label field; 294 3. use the flow label to control packet switching; 295 4. use the flow label specifically to extend the existing 296 differentiated services QoS architecture; 297 5. other uses. 299 Among the proposals described in the following five sections, various 300 methods are proposed to set up the flow label value. It should be 301 noted that some of these proposals embody novel and perhaps 302 controversial approaches to QoS provision, and these cannot readily 303 be separated from their use of the flow label. We give a reasonable 304 amount of technical detail for some of the proposals, to show the 305 extent to which they propose detailed semantics for the flow label 306 value. 308 3.1. Specify the flow label as a pseudo-random value 310 3.1.1. End-to-End QoS Provisioning 312 As our first example, [Lin06] specifies a 17-bit pseudo-random value. 313 The figure below shows the proposed flow label structure. 315 o The Label Flag (LF) bit: 1 means this type of flow label is 316 present. We note that this encoding is incompatible with the 317 dependency prohibition in [RFC3697], since a source that does not 318 use this method may also set the LF bit. 319 o The Label type (LT): 2 bits which describe the type of packet. 320 o The Label Number (LN): which is randomly generated by the source 321 node. 323 [Lin06] also describes a signalling process between source, routing 324 and destination nodes based on this label structure and on the IPv6 325 Traffic Class byte, in order to reserve and release router resources 326 for a given flow within a given class of traffic. The pseudo-random 327 LN value is used to uniquely identify a given flow. 329 Flow Label Specification (figure simplified from [Lin06]) 331 +--+----+-----------------------------+ 332 | 1| 2 | 17 bits | 333 +--+----+-----------------------------+ 334 |LF| LT | LN | 335 +--+----+-----------------------------+ 337 LF 0 Disable 338 1 Enable 339 LT 00 Flow label requested by source 340 01 Flow label returned by destination 341 10 Flow label for data delivery 342 11 Flow label terminates connection 343 LN Random number created by source 345 3.1.2. Load balancing 347 There have been numerous informal discussions of using pseudo-random 348 flow labels to allow load-balancing or at least load-sharing. This 349 would be achieved by including the flow label value among the fields 350 in each packet header used as input to a modulo(N) hash used to 351 select among N alternative paths. However, concerns about the 352 interpretation of the dependency prohibition have generally prevented 353 such proposals from being written up until recently 354 [I-D.ietf-6man-flow-ecmp]. 356 3.1.3. Security nonce 358 Another proposal for a pseudo-random flow label value is 359 [I-D.blake-ipv6-flow-label-nonce]. This states that off-path 360 spoofing attacks have become a big issue for TCP and other transport- 361 layer applications, and proposes that in IPv6 we should set a random 362 value in the flow label to make the packet header more complex and 363 less easy for the attacker to guess. The two ends of the session 364 will agree on flow label values during the SYN/ACK exchange, but off- 365 path attackers will be unlikely to guess the agreed value. 366 Naturally, on-path attackers who can observe the flow labels in use 367 can trivially defeat this protection. This proposal does not involve 368 using the flow label value to retrieve routing state. 370 3.2. Specify QoS parameters in the flow label 372 [Prakash04] proposes to utilize the flow label to indicate required 373 QoS parameters in detail. It uses the first few bits of the flow 374 label field as codes to support different approaches, as summarized 375 in following table. Again, this is incompatible with the dependency 376 prohibition in [RFC3697], since a source that does not use this 377 method may also set the first two bits to non-zero. 379 Classification for various approaches (from [Prakash04]) 381 Bit Pattern Approach 382 ------------------------------------------------------------------ 383 00 No QoS requirement (Default QoS value) 384 01 Pseudo-Random value used for the value of Flow-Label 385 10 Support for Direct Parametric Representation 386 1100 Support for the DiffServ Model 387 1101 Reserved for future use 388 111 Reserved for future use 390 This method allows a pseudo-random option, but also adds options for 391 a direct QoS request and for Diffserv. In the direct QoS parameters 392 approach, 18 bits are used to encode requirements for one way delay, 393 IP delay variation, bandwidth and one way packet loss. The proposal 394 appears to assume that RSVP [RFC2205] mechanisms are used to actually 395 implement these QoS parameters. 397 This proposal allows use of flow label for various important QoS 398 models, so the end user and service provider can choose the most 399 suitable model for their situation; [Prakash04] claims that "this 400 proposal is simple, scalable, modular and generic implementation to 401 provide for QoS using the IPv6 flow label field". 403 Similarly, [Lee04] defines the flow label field in five parts, with 404 the first 3 bits used as an approach type. The authors define two 405 approaches: a "random" scheme and a "hybrid" scheme. If the first 3 406 bits equal "001", the flow label will be used as the random 407 identifier of the flow, but if they equal "101", the remaining bits 408 will include a hybrid QoS requirement for this packet, subdivided 409 into traffic type (stringent or best effort), bandwidth, buffer, and 410 delay requirements. Once again the dependency prohibition in 411 [RFC3697] is broken. This proposal also includes throughput 412 monitoring and dynamic capacity allocation. Effectively this 413 proposal uses the flow label both to signal Intserv-like QoS 414 requirements and to classify traffic into Diffserv-like virtual 415 label-switched paths. Packets with a "random" flow label are mapped 416 into a generic (best effort) virtual path. 418 3.3. Use flow label hop-by-hop to control switching 420 [I-D.chakravorty-6lsa] and [Chakravorty08a] describe an architectural 421 framework called "IPv6 Label Switching Architecture" (6LSA). In 422 6LSA, network components identify a flow by looking at the flow label 423 field in the IPv6 packet header; all packets with the same flow label 424 must receive the same treatment and be sent to the same next hop. 425 However, 6LSA resembles MPLS by considering that a label only has 426 meaning between 6LSA routers, and setting the flow label at each hop. 427 If the original source sets a non-zero flow label, there is no 428 mechanism to restore it before delivery, a fundamental breach of 429 [RFC3697]. The authors of [I-D.chakravorty-6lsa] did at one stage 430 discuss using an IPv6 hop-by-hop option to correct this problem, but 431 this has not been documented. This is a more serious incompatibility 432 than simply breaking the dependency prohibition 434 Unlike traditional routing algorithms, but like MPLS, 6LSA packets 435 are classified into a Forwarding Equivalence Class (FEC), and routers 436 forward packets on different paths by looking at the FEC. Like 437 previous solutions, the authors divide the flow label field into 438 three parts. The first 3 bits identify the FEC, which will help the 439 router or 6LSA nodes to group the IP packets that receive the same 440 forwarding treatment and forwarding them on the same virtual path. 441 The following 4 bits describe the application type, and the final 13 442 bits (defined by each node or a group of nodes) specify the hop- 443 specific label. From the table below, we can see the FEC has 6 major 444 categories, each with up to 16 subcategories. 446 Flow Label Specification (shortened from [I-D.chakravorty-6lsa]) 448 +--------------------------+-------------+--------------------------+ 449 | FEC (First 3 Bits) | Next 4 Bits | Purpose | 450 +--------------------------+-------------+--------------------------+ 451 | No FEC (000) | 0000 | | 452 | Domain Specific (000) | 0001 - 1111 | | 453 | ------------------------ | | | 454 | VPN (001) | 0001 | (IPSec - Tunnel Mode) | 455 | | 0010 | (IPSec - Transport Mode) | 456 | | 0011 | (Special Encryption) | 457 | | 0100 | (VRF) | 458 | | 0101 | (End Network Specific) | 459 | | 0110 - 1111 | (Reserved) | 460 | ------------------------ | | | 461 | TE Subset/ | 0001 | (DiffServ) | 462 | QoS Enhancement (010) | 0010 | (RSVP) | 463 . . . 464 | | 1111 | (Reserved) | 465 | ------------------------ | | | 466 | Encapsulation (011) | 0001 | (IPv6 in IPv6) | 467 | | 0010 | (IPv4 in IPv6) | 468 | | 0011 | (Other in IPv6) | 469 | | 0100 | (Enterprise Specific) | 470 | | 0101 - 1111 | (Reserved) | 471 | ------------------------ | | | 472 | Enterprise Specific(111) | 0000 - 1111 | (Reserved) | 473 +--------------------------+-------------+--------------------------+ 475 The authors claim that fast switching using 20-bit labels instead of 476 128-bit IPv6 addresses will provide memory and processing savings, as 477 well as network management advantages. "It also allows a network 478 management entity updating available label tables, across the network 479 to reduce man-in-the-middle attacks [sic]" [I-D.chakravorty-6lsa]. 481 We note that a similar proposal for QoS-based switching of IPv6 482 packets [I-D.roberts-inband-qos-ipv6] is designed to use a hop-by-hop 483 option, which has not so far been allocated by the IETF. Proposals 484 related to this have been discussed by the Telecommunications 485 Industry Association and the ITU-T 486 [I-D.adams-tsvwg-flow-signalling-codepoint]. 488 We also note that router lookup efficiency was a major concern at the 489 time when Clark first proposed a flow label [Deering93], but with the 490 advent of very large scale integrated circuits capable of rapid 491 lookup in a routing table, most vendors no longer express such 492 concern. 494 3.4. Diffserv use of IPv6 flow label 496 [I-D.banerjee-flowlabel-ipv6-qos] uses the flow label field as a 497 replacement for the IPv6 Traffic Class field; this proposal suggests 498 the incoming flow label can indicate the QoS requirement by matching 499 a Diffserv classifier. The authors have used the first three bits to 500 indicate this, and the following 16 bits to indicate a Differentiated 501 Services Per-Hop Behavior Identification code (Diffserv PHB-ID) 502 [RFC3140]; the last bit is reserved for future use. This method too 503 breaks the dependency prohibition in [RFC3697]. 505 [I-D.martinbeckman-ietf-ipv6-fls-ipv6flowswitching] blends the flow 506 label as an MPLS-like switching tag with Diffserv. Unlike 6LSA, the 507 method attempts to bypass the dependency prohibition by using one bit 508 in the Diffserv Code Point [RFC2474] to indicate that the flow label 509 is a switching tag. In this way, a router can determine whether the 510 flow label conforms to [RFC3697] or to 511 [I-D.martinbeckman-ietf-ipv6-fls-ipv6flowswitching]. In 512 [I-D.martinbeckman-ietf-ipv6-amp-ipv6hcamp], the same author proposes 513 using the flow label as a way of compressing IPv6 headers by hashing 514 the addresses into the flow label, again using the Diffserv Code 515 Point to mark the packets accordingly. 517 3.5. Other uses 519 The Integrated Services QoS architecture [RFC1633] specifies that the 520 flow label may be used as a packet filter [RFC2205]. At least one 521 implementation supported this [Braden10]. 523 We are not aware of any proposals combining the flow label with the 524 Next Steps in Signaling (NSIS) [RFC4080] architecture. 526 [I-D.donley-softwire-dslite-flowlabel] proposes a use case whereby 527 certain flows encapsulated in a particular type of IPv4-in-IPv6 528 tunnel would be distinguished at the remote end of the tunnel by a 529 specific flow label value. This would allow a service provider to 530 deliver a tailored quality of service. This usage appears to be 531 completely compatible with [RFC3697]. 533 There has been some discussion of possible flow label use in both the 534 ROLL (Routing Over Low power and Lossy networks) [RPL-07] and MEXT 535 (Mobility EXTensions for IPv6) working groups of the IETF. Such uses 536 tend to encode specific local meanings or routing-related tags in the 537 label, so they appear to infringe the dependency prohibition or the 538 immutability of the flow label field. The ROLL group has indeed most 539 recently opted not to use the flow label field for these reasons, 540 despite having to add the undesirable overhead of an IPv6 hop-by-hop 541 option instead [I-D.ietf-roll-rpl]. Similarly, MEXT has defined a 542 new mobility option to support flow bindings 543 [I-D.ietf-mext-flow-binding], rather than using the IPv6 flow label 544 field. 546 4. Conclusion 548 Three aspects of the current standard [RFC3697] have caused problems 549 to many designers: 550 1. The immutability of labels 551 2. "Nodes MUST NOT assume any mathematical or other properties of 552 the Flow Label" 553 3. "Router performance SHOULD NOT be dependent on the distribution 554 of the Flow Label values." 556 Taken together, these rules essentially forbid any encoding of the 557 semantics of a flow, or of any information about its path, in the 558 flow label. This was intentional, in accordance with the stateless 559 nature of the Internet architecture and with the end-to-end principle 560 [Saltzer84], [RFC3724]. It was also felt that QoS encoding via 561 Diffserv was sufficient, and that the requirement for high-speed 562 switching could be met by MPLS. But this means that the majority of 563 the proposals described above breach the standard and the intent of 564 the standard. The authors often appear to be using the flow label 565 either as an MPLS-like switching handle, or as an encoded QoS signal. 567 In contrast, a few documents metioned above do appear to respect the 568 rules of RFC 3697. These are [I-D.blake-ipv6-flow-label-nonce], 569 [I-D.donley-softwire-dslite-flowlabel], [I-D.ietf-6man-flow-ecmp], 570 [I-D.martinbeckman-ietf-ipv6-fls-ipv6flowswitching] and 571 [I-D.martinbeckman-ietf-ipv6-amp-ipv6hcamp]. Additionally, [Lin06] 572 would have joined this list if it had not assigned three flag bits in 573 the flow label field. Although predating RFC 3697, the Integrated 574 Services usage [RFC2205] also seems to be compatible. 576 What would other designers need to do, if they wish to respect RFC 577 3697? There appear to be two choices. One is to simply accept the 578 existing rules at face value, as in the proposals just listed. This 579 limits the application of the flow label. It can, for example, be 580 used as a nonce or as part of the material for a hash used to share 581 load among alternate paths. It cannot be the only material for such 582 a hash, because of the dependency prohibition. The flow label could 583 also be used consistently with RFC 3697, if an application designer 584 so chose, as a way to associate all packets belonging to a given 585 application session between two hosts, across multiple transport 586 sessions. This, however, would presumably exclude using the flow 587 label to govern routing decisions in any way, and would have 588 widespread implications that have never been explored. 590 The other choice, for designers who wish to use the flow label to 591 control switching or QoS directly, is to bypass the rules within a 592 given domain (a set of cooperating nodes) in a way that nodes outside 593 the domain cannot detect. In this case, any deviation from RFC 3697 594 has no possible effect outside the domain in question. 596 An example scheme to emulate the immutability of labels is as 597 follows. Within the domain, all hosts set the label to zero, the 598 routers set and interpret the label in any way they wish, and the 599 last hop router always sets the label back to zero. If a packet 600 arrives from outside the domain with a non-zero label, there is a 601 method (such as a special Diffserv code point) to mark this packet so 602 that its label would be ignored and delivered unchanged. An 603 alternative approach would be to define a hop-by-hop option to carry 604 the original flow label across the domain, so that it could be 605 changed within the domain but restored before forwarding the packet 606 beyond the domain. 608 If a domain allows mutable labels in such a way, it may safely ignore 609 the dependency prohibition, and it may set the bits in the label 610 according to locally defined rules. Within the domain, the label 611 could be used as desired, and most of the proposed designs discussed 612 above could be "rescued." 614 However, given the considerable number of designers who have proposed 615 solutions incompatible with RFC 3697, the relatively few designs 616 using the standard rules, and the failure of designs such as ROLL and 617 MEXT to make use of the flow label, it seems reasonable to ask 618 whether the RFC 3697 standard has value. 620 5. Security Considerations 622 The flow label is not protected in any way and can be forged by an 623 on-path attacker. Off-path attackers may be able to guess a valid 624 flow label unless a pseudo-random value is used. Specific usage 625 models for the flow label need to allow for these exposures. For 626 further discussion, see [RFC3697]. 628 6. IANA Considerations 630 This document requests no action by IANA. 632 7. Acknowledgements 634 An invaluable review of this document was performed by Bob Braden. 636 Helpful comments were made by Sheng Jiang. 638 This document was produced using the xml2rfc tool [RFC2629]. 640 8. Change log 642 draft-hu-flow-label-cases-00: first I-D version, 2010-04-19 644 draft-hu-flow-label-cases-01: updated following review comments, 645 2010-08-18 647 draft-hu-flow-label-cases-02: updated following more review comments, 648 2010-09-30 650 draft-hu-flow-label-cases-03: updated following more review comments, 651 2011-02-23 653 9. Informative References 655 [Braden10] 656 Braden, R., "Private Communication", 2010. 658 [Carpenter02] 659 Carpenter, B. and K. Nichols, "Differentiated Services in 660 the Internet", Proc IEEE 90 (9) 1479-1494, 2002. 662 [Chakravorty08a] 663 Chakravorty, S., "Challenges of IPv6 Flow Label 664 implementation", Proc IEEE MILCOM2008 , 2008. 666 [Conta01a] 667 Conta, A. and B. Carpenter, "A proposal for the IPv6 Flow 668 Label Specification", draft-conta-ipv6-flow-label-02 (work 669 in progress), July 2001. 671 [Deering93] 672 Deering, S., "SIPP Overview and Issues", Minutes of the 673 Joint Sessions of the SIP and PIP Working Groups , 674 November 1993. 676 [Hagino01] 677 Hagino, J., "Socket API for IPv6 flow label field", 678 draft-itojun-ipv6-flowlabel-api-01 (work in progress), 679 April 2001. 681 [I-D.adams-tsvwg-flow-signalling-codepoint] 682 song, j., Adams, J., and J. Joung, "Progress and future 683 development of Flow State Aware standards, and a proposal 684 for alerting nodes or end-systems on data related to a 685 flow", draft-adams-tsvwg-flow-signalling-codepoint-00 686 (work in progress), June 2008. 688 [I-D.banerjee-flowlabel-ipv6-qos] 689 Banerjee, R., "A Modified Specification for use of the 690 IPv6 Flow Label for providing An efficient Quality of 691 Service using hybrid approach", 692 draft-banerjee-flowlabel-ipv6-qos-03 (work in progress), 693 April 2002. 695 [I-D.blake-ipv6-flow-label-nonce] 696 Blake, S., "Use of the IPv6 Flow Label as a Transport- 697 Layer Nonce to Defend Against Off-Path Spoofing Attacks", 698 draft-blake-ipv6-flow-label-nonce-02 (work in progress), 699 October 2009. 701 [I-D.chakravorty-6lsa] 702 Chakravorty, S., Bush, J., and J. Bound, "IPv6 Label 703 Switching Architecture", draft-chakravorty-6lsa-03 (work 704 in progress), July 2008. 706 [I-D.conta-diffserv-ipv6-fl-classifier] 707 Conta, A. and J. Rajahalme, "Amodel for Diffserv use of 708 the IPv6 Flow Label Specification", 709 draft-conta-diffserv-ipv6-fl-classifier-01 (work in 710 progress), November 2001. 712 [I-D.donley-softwire-dslite-flowlabel] 713 Donley, C. and K. Erichsen, "Using the Flow Label with 714 Dual-Stack Lite", 715 draft-donley-softwire-dslite-flowlabel-01 (work in 716 progress), January 2011. 718 [I-D.ietf-6man-flow-ecmp] 719 Carpenter, B. and S. Amante, "Using the IPv6 flow label 720 for equal cost multipath routing and link aggregation in 721 tunnels", draft-ietf-6man-flow-ecmp-01 (work in progress), 722 February 2011. 724 [I-D.ietf-6man-flow-update] 725 Amante, S., Carpenter, B., and S. Jiang, "Rationale for 726 update to the IPv6 flow label specification", 727 draft-ietf-6man-flow-update-02 (work in progress), 728 January 2011. 730 [I-D.ietf-mext-flow-binding] 731 Tsirtsis, G., Soliman, H., Montavont, N., Giaretta, G., 732 and K. Kuladinithi, "Flow Bindings in Mobile IPv6 and NEMO 733 Basic Support", draft-ietf-mext-flow-binding-11 (work in 734 progress), October 2010. 736 [I-D.ietf-roll-rpl] 737 Winter, T., Thubert, P., Brandt, A., Clausen, T., Hui, J., 738 Kelsey, R., Levis, P., Pister, K., Struik, R., and J. 739 Vasseur, "RPL: IPv6 Routing Protocol for Low power and 740 Lossy Networks", draft-ietf-roll-rpl-18 (work in 741 progress), February 2011. 743 [I-D.martinbeckman-ietf-ipv6-amp-ipv6hcamp] 744 Beckman, M., "IPv6 Header Compression via Addressing 745 Mitigation Protocol (IPv6 AMP)", 746 draft-martinbeckman-ietf-ipv6-amp-ipv6hcamp-01 (work in 747 progress), March 2007. 749 [I-D.martinbeckman-ietf-ipv6-fls-ipv6flowswitching] 750 Beckman, M., "IPv6 Dynamic Flow Label Switching (FLS)", 751 draft-martinbeckman-ietf-ipv6-fls-ipv6flowswitching-03 752 (work in progress), March 2007. 754 [I-D.roberts-inband-qos-ipv6] 755 Roberts, L. and J. Harford, "In-Band QoS Signaling for 756 IPv6", draft-roberts-inband-qos-ipv6-00 (work in 757 progress), July 2005. 759 [Lee04] Lee, I. and S. Kim, "A QoS Improvement Scheme for Real- 760 Time Traffic Using IPv6 Flow Labels", Lecture Notes in 761 Computer Science Vol. 3043, 2004. 763 [Lin06] Lin, C., Tseng, P., and W. Hwang, "End-to-End QoS 764 Provisioning by Flow Label in IPv6", JCIS , 2006. 766 [Metzler00] 767 Metzler, J. and S. Hauth, "An end-to-end usage of the IPv6 768 flow label", draft-metzler-ipv6-flowlabel-00 (work in 769 progress), November 2000. 771 [Prakash04] 772 Prakash, B., "Using the 20 bit flow label field in the 773 IPv6 header to indicate desirable quality of service on 774 the internet", University of Colorado (M.Sc. Thesis), 775 2004. 777 [RFC1633] Braden, B., Clark, D., and S. Shenker, "Integrated 778 Services in the Internet Architecture: an Overview", 779 RFC 1633, June 1994. 781 [RFC1707] McGovern, M. and R. Ullmann, "CATNIP: Common Architecture 782 for the Internet", RFC 1707, October 1994. 784 [RFC1710] Hinden, R., "Simple Internet Protocol Plus White Paper", 785 RFC 1710, October 1994. 787 [RFC1752] Bradner, S. and A. Mankin, "The Recommendation for the IP 788 Next Generation Protocol", RFC 1752, January 1995. 790 [RFC1809] Partridge, C., "Using the Flow Label Field in IPv6", 791 RFC 1809, June 1995. 793 [RFC1883] Deering, S. and R. Hinden, "Internet Protocol, Version 6 794 (IPv6) Specification", RFC 1883, December 1995. 796 [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. 797 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 798 Functional Specification", RFC 2205, September 1997. 800 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 801 (IPv6) Specification", RFC 2460, December 1998. 803 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 804 "Definition of the Differentiated Services Field (DS 805 Field) in the IPv4 and IPv6 Headers", RFC 2474, 806 December 1998. 808 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 809 June 1999. 811 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 812 Label Switching Architecture", RFC 3031, January 2001. 814 [RFC3140] Black, D., Brim, S., Carpenter, B., and F. Le Faucheur, 815 "Per Hop Behavior Identification Codes", RFC 3140, 816 June 2001. 818 [RFC3697] Rajahalme, J., Conta, A., Carpenter, B., and S. Deering, 819 "IPv6 Flow Label Specification", RFC 3697, March 2004. 821 [RFC3724] Kempf, J., Austein, R., and IAB, "The Rise of the Middle 822 and the Future of End-to-End: Reflections on the Evolution 823 of the Internet Architecture", RFC 3724, March 2004. 825 [RFC4080] Hancock, R., Karagiannis, G., Loughney, J., and S. Van den 826 Bosch, "Next Steps in Signaling (NSIS): Framework", 827 RFC 4080, June 2005. 829 [RPL-07] Winter, T. and P. Thubert, "RPL: IPv6 Routing Protocol for 830 Low power and Lossy Networks", draft-ietf-roll-rpl-07 831 (work in progress), March 2010. 833 [Saltzer84] 834 Saltzer, J., Reed, D., and D. Clark, "End-To-End Arguments 835 in System Design", ACM TOCS 2 (4) 277-288, 1984. 837 Authors' Addresses 839 Qinwen Hu 840 Department of Computer Science 841 University of Auckland 842 PB 92019 843 Auckland, 1142 844 New Zealand 846 Email: qhu009@aucklanduni.ac.nz 848 Brian Carpenter 849 Department of Computer Science 850 University of Auckland 851 PB 92019 852 Auckland, 1142 853 New Zealand 855 Email: brian.e.carpenter@gmail.com