idnits 2.17.1 draft-ietf-6man-flow-update-02.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 : ---------------------------------------------------------------------------- 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 seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (January 31, 2011) is 4833 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'I-D.draft-ietf-6man-flow-3697bis' is mentioned on line 321, but not defined == Missing Reference: 'I-D.ietf-6man-flow-3697bis' is mentioned on line 247, but not defined == Unused Reference: 'RFC2119' is defined on line 369, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) == Outdated reference: A later version (-03) exists of draft-gont-6man-flowlabel-security-01 == Outdated reference: A later version (-03) exists of draft-hu-flow-label-cases-02 -- Obsolete informational reference (is this intentional?): RFC 2629 (Obsoleted by RFC 7749) -- Obsolete informational reference (is this intentional?): RFC 3697 (Obsoleted by RFC 6437) Summary: 1 error (**), 0 flaws (~~), 7 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 6MAN S. Amante 3 Internet-Draft Level 3 4 Intended status: Informational B. Carpenter 5 Expires: August 4, 2011 Univ. of Auckland 6 S. Jiang 7 Huawei Technologies Co., Ltd 8 January 31, 2011 10 Rationale for update to the IPv6 flow label specification 11 draft-ietf-6man-flow-update-02 13 Abstract 15 Various published proposals for use of the IPv6 flow label are 16 incompatible with its original specification in RFC 3697. 17 Furthermore, very little practical use is made of the flow label, 18 partly due to some uncertainties about the correct interpretation of 19 the specification. This document discusses and motivates changes to 20 the specification in order to clarify it, and to introduce some 21 additional flexibility. 23 Status of this Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on August 1, 2011. 40 Copyright Notice 42 Copyright (c) 2011 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Impact of current specification . . . . . . . . . . . . . . . 4 59 3. Changes to specification . . . . . . . . . . . . . . . . . . . 6 60 4. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 7 61 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 62 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 63 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 64 8. Change log . . . . . . . . . . . . . . . . . . . . . . . . . . 8 65 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 66 9.1. Normative References . . . . . . . . . . . . . . . . . . . 9 67 9.2. Informative References . . . . . . . . . . . . . . . . . . 9 68 Appendix A. Alternative Approaches . . . . . . . . . . . . . . . 10 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 71 1. Introduction 73 The flow label field in the IPv6 header was reserved but left 74 experimental by [RFC2460], which mandates only that "Hosts or routers 75 that do not support the functions of the Flow Label field are 76 required to set the field to zero when originating a packet, pass the 77 field on unchanged when forwarding a packet, and ignore the field 78 when receiving a packet." 80 The flow label field was normatively specified by [RFC3697]. In 81 particular, we quote three rules from that RFC: 82 a. "The Flow Label value set by the source MUST be delivered 83 unchanged to the destination node(s)." 84 b. "IPv6 nodes MUST NOT assume any mathematical or other properties 85 of the Flow Label values assigned by source nodes." 86 c. "Router performance SHOULD NOT be dependent on the distribution 87 of the Flow Label values. Especially, the Flow Label bits alone 88 make poor material for a hash key." 90 Additionally, RFC 3697 leaves it undefined what method a host should 91 adopt by default to choose the value of the flow label, if no 92 specific method is in use. It was expected that various signalling 93 methods might be defined for agreeing on values of the flow label, 94 but no such methods have been standardised. 96 RFC 2460 mandates only that "Hosts or routers that do not support the 97 functions of the Flow Label field are required to set the field to 98 zero when originating a packet, pass the field on unchanged when 99 forwarding a packet, and ignore the field when receiving a packet." 101 The flow label is hardly used in practice in existing IPv6 102 implementations. To some extent this is due to the main focus being 103 on basic deployment of IPv6, but the absence of a default method of 104 choosing the flow label value means that most host implementations 105 simply set it to zero. There is also anecdotal evidence that the 106 rules quoted above have led to uncertainty about exactly what is 107 possible. Furthermore, various use cases have been proposed that 108 infringe one or another of the rules. None of these proposals has 109 been accepted as a standard and in practice there is no significant 110 deployment of any mechanism to set the flow label. 112 The intention of this document is to explain this situation in more 113 detail and to motivate changes to RFC 3697 intended to remove the 114 uncertainties and encourage active usage of the flow label. It does 115 not formally update RFC 3697. 117 2. Impact of current specification 119 Rule (a) makes it impossible for the routing system to use the flow 120 label as any form of dynamic routing tag. This was a conscious 121 choice in the early design of IPv6 and there appears to be no 122 practical possibility of revisiting this choice at this stage in the 123 deployment of IPv6, which uses conventional routing mechanisms like 124 those used for IPv4. However, this rule also makes it impossible to 125 make any use at all of the flow label unless hosts choose to set it. 126 It also forbids clearing the flow label for security reasons. 128 This last point highlights the security properties, or rather the 129 lack of them, of the flow label. The flow label field is always 130 unprotected as it travels through the network, because there is no 131 IPv6 header checksum, and the flow label is not included in transport 132 pseudo-header checksums, nor in IPsec checksums. As a result, 133 intentional and malicious changes to its value cannot be detected. 134 Also, it could be used as a covert data channel, since apparently 135 pseudo-random flow label values could in fact consist of covert data. 136 If the flow label were to carry quality of service semantics, then 137 like the diffserv code point [RFC2474], it would not be intrinsically 138 trustworthy across domain boundaries. As a result, some security 139 specialists believe that flow labels should be cleared for safety. 140 These points must be considered when discussing the immutability of 141 the flow label across domain boundaries. 143 Rule (b) appears to forbid any usage in which the bits of the flow 144 label are encoded with a specific semantic meaning. If the word 145 "alone" is overlooked, rule (c) has sometimes been interpreted to 146 forbid the use of the flow label as part of a hash used by load 147 balancing mechanisms. 149 Both before and after these rules were laid down, a considerable 150 number of proposals for use of the flow label were published that 151 seem incompatible with them. Numerous examples and an analysis are 152 presented in [I-D.hu-flow-label-cases]. Those examples propose use 153 cases in which some or all of the following apply: 154 o The flow label may be changed by intermediate systems. 155 o It doesn't matter if the flow label is changed, because the 156 receiver doesn't use it. 157 o Some or all bits of the flow label are encoded: they have specific 158 meanings understood by routers and switches along the path. 159 o The encoding is related to the required quality of service, as 160 well as identifying a flow. 161 o The flow label is used to control forwarding or switching in some 162 way. 164 These proposals all require either some form of encoding of semantics 165 in the bits of the flow label, or the ability for routers to modify 166 the flow label, or both. Thus they appear to infringe the rules from 167 RFC 3697 quoted above. 169 We can conclude that a considerable number of researchers and 170 designers have been stymied by RFC 3697. On the other hand, some 171 other proposals discussed in [I-D.hu-flow-label-cases] appear to be 172 compatible with RFC 3697. Several are based on the originator of a 173 packet choosing a pseudo-random flow label for each flow, which is 174 one option suggested in RFC 3697. Thus, we can also conclude that 175 there is a useful role for this approach. 177 If our goal is for the flow label to be used in practice, the 178 conflict between the various approaches creates a dilemma. There 179 appear to be two major options: 180 1. Discourage locally defined use of the flow label. Strengthen RFC 181 3697 to say that hosts SHOULD set a pseudo-random label value, 182 which would clarify and limit its possible uses. In particular, 183 its use for load balancing would be encouraged. 184 2. Relax the rules to encourage locally defined use of the flow 185 label. This approach would make the flow label completely 186 mutable and would exclude use cases depending on strict end-to- 187 end immutability. It would encourage applications of a pseudo- 188 random flow label, such as load balancing, on a local basis, but 189 it would exclude end-to-end applications. 191 During 2010 there has been considerable debate about these options 192 and variants of them, with a variety of proposals in previous 193 versions of this document and in mailing list discussions. After 194 these discussions, there appears to be a view that simplicity should 195 prevail, and that complicated proposals such as defining quality of 196 service semantics in the flow label, or sub-dividing the flow label 197 field into smaller sub-fields, will not prove efficient or 198 deployable, especially in high speed routers. There is also a 199 clearly expressed view that using the flow label for various forms of 200 stateless load balancing is the best simple application for it. At 201 the same time, it is necessary to recognize that the strict 202 immutability rule has drawbacks as noted above. 204 Even under the rules of RFC 3697, the flow label is intrinsically 205 untrustworthy, because modifications en route cannot be detected. 206 For this reason, even with the current strict immutability rule, 207 downstream nodes cannot rely on the value being unchanged. In this 208 sense, any use of the flow label must be viewed as an optimisation on 209 a best effort basis; a packet with a changed (or zero) flow label 210 value should never cause a hard failure. 212 The remainder of this document discusses specific modifications to 213 the standard, which are defined normatively in a companion document 214 [I-D.draft-ietf-6man-flow-3697bis]. 216 3. Changes to specification 218 Although RFC 3697 requires the flow label to be delivered unchanged, 219 as noted above, it is not included in any transport layer pseudo- 220 header checksums nor in IPsec authentication [RFC4302]. Both RFC 221 2460 and RFC 3697 define the default flow label to be zero. At the 222 time of writing, this is the observed value in an overwhelming 223 proportion of IPv6 packets; neither operating systems nor 224 applications currently set it, and routers do not rely on it. Thus 225 there is no reason to expect operational difficulties if a careful 226 change is made to the rules of RFC 3697. 228 In particular, the facts that the label is not checksummed and rarely 229 used mean that the current strict immutability of the label can be 230 moderated without operational consequences. 232 The purposes of the proposed changes are to remove the uncertainties 233 left by RFC 3697, in order to encourage setting of the flow label by 234 default, and to enable its generic use. The proposed generic use is 235 to encourage pseudo-random flow labels that can be used to assist 236 load balancing. There should be no impact on existing IETF 237 specifications other than RFC 3697 and no impact on currently 238 operational software and hardware. 240 A secondary purpose is to modify the immutability of the flow label 241 in a limited way, to allow hosts that do not set the flow label to 242 benefit from it nevertheless. The fact that the flow label may in 243 practice be changed en route is also reflected in the reformulation 244 of the rules. 246 A general description of the changes follows. The normative text is 247 to be found in [I-D.ietf-6man-flow-3697bis]. 249 The definition of a flow is subtly changed from RFC 3697 to allow any 250 node, not just the source node, to set the flow label value. 251 However, it is recommended that sources should set a pseudo-random 252 flow label value in all flows, replacing the less precise 253 recommendation made in Section 3 of RFC 3697. Both stateful and 254 stateless methods of assigning a pseudo-random value could be used. 256 Section 3 of RFC 3697 also allows nodes to participate in an 257 unspecified method of flow state establishment. The changes do not 258 remove that option, but it is made clear that stateless models are 259 also possible. 261 The main novelty is that a forwarding node (typically a first-hop or 262 ingress router) may set the flow label value if the source has not 263 done so, according to the same recommendations that apply to the 264 source. This might place a considerable processing load on ingress 265 routers, even if they adopted a stateless method of flow 266 identification and label assignment. 268 The immutability of the flow label, once it has been set, is not 269 changed. However, some qualifications are placed on this property, 270 to allow for the fact that the flow label is an unprotected field and 271 might be changed undetectably. No Internet-wide mechanism can depend 272 mathematically on immutable flow labels. The new rules require that 273 flow labels exported to the Internet must always be either zero or 274 pseudo-random, but even this cannot be relied on mathematically. Use 275 cases need to be robust against non-conforming flow label values. 277 4. Discussion 279 The following are some practical consequences of the above changes: 280 o Sending hosts that are not updated will in practice continue to 281 send all-zero labels. If there is no label-setting router along 282 the path taken by a packet, the label will be delivered as zero. 283 o Sending hosts conforming to the new specification will by default 284 choose pseudo-random labels between 1 and 0xFFFFF. 285 o Sending hosts may continue to send all-zero labels, in which case 286 an ingress router may set pseudo-random labels between 1 and 287 0xFFFFF. 288 o The flow label is no longer unrealistically asserted to be 289 strictly immutable; it is recognised that it may, incorrectly, be 290 changed en route. In some circumstances this will break end-to- 291 end usage, e.g. potential detection of third-party spoofing 292 attacks [I-D.gont-6man-flowlabel-security]. 293 o The expected default usage of the flow label is some form of 294 stateless load distribution, such as the ECMP/LAG usage defined in 295 [I-D.carpenter-flow-ecmp]. 296 o If the new rules are followed, all IPv6 traffic flows on the 297 Internet should have zero or pseudo-random flow label values. 299 From an operational viewpoint, existing IPv6 hosts that set a default 300 (zero) flow label value and ignore the flow label on receipt will be 301 unaffected by implementations of the new specification. In general, 302 it is assumed that hosts will ignore the value of the flow label on 303 receipt; it cannot be relied on as an end-to-end signal. However, 304 this doesn't apply if a cryptographically generated label is being 305 used to detect attackers [I-D.gont-6man-flowlabel-security]. 307 Similarly, routers that ignore the flow label will be unaffected by 308 implementations of the specification. 310 Hosts that set a default (zero) flow label but are in a domain where 311 routers set a pseudo-random label as recommended in Section 3 will 312 benefit from whatever flow label handling is used on the path. 314 Hosts and routers that adopt the recommended pseudo-random mechanism 315 will enhance the performance of any load balancing devices that 316 include the flow label in the hash used to select a particular path 317 or server, even when packets leave the local domain. 319 5. Security Considerations 321 See [I-D.draft-ietf-6man-flow-3697bis] and 322 [I-D.gont-6man-flowlabel-security] for full discussion. 324 6. IANA Considerations 326 This document requests no action by IANA. 328 7. Acknowledgements 330 The authors are grateful to Qinwen Hu for general discussion about 331 the flow label and for his work in searching the literature. 332 Valuable comments and contributions were made by Fred Baker, Steve 333 Blake, Remi Despres, Alan Ford, Fernando Gont, Brian Haberman, Tony 334 Hain, Joel Halpern, Chris Morrow, Thomas Narten, Mark Smith, Pascal 335 Thubert, Iljitsch van Beijnum, and other participants in the 6man 336 working group. 338 This document was produced using the xml2rfc tool [RFC2629]. 340 8. Change log 342 draft-ietf-6man-flow-update-02: repurposed as rationale for update of 343 RFC 3697, 2011-01-31 345 draft-ietf-6man-flow-update-01: clarified that this is not a formal 346 update of RFC 3697, clarified text about domains exporting 347 inappropriate labels, 2011-01-10 349 draft-ietf-6man-flow-update-00: adopted as WG document at IETF 79, 350 mutability rules adjusted according to WG discussion, 2010-12-03 351 draft-carpenter-6man-flow-update-04: even more simplified according 352 to WG discussion, 2010-09-16 354 draft-carpenter-6man-flow-update-03: futher simplified according to 355 WG discussion, 2010-05-07 357 draft-carpenter-6man-flow-update-02: revised and simplified according 358 to WG discussion, 2010-04-13 360 draft-carpenter-6man-flow-update-01: revised according to mail list 361 discussion, 2010-03-05 363 draft-carpenter-6man-flow-update-00: original version, 2010-02-18 365 9. References 367 9.1. Normative References 369 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 370 Requirement Levels", BCP 14, RFC 2119, March 1997. 372 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 373 (IPv6) Specification", RFC 2460, December 1998. 375 9.2. Informative References 377 [I-D.carpenter-flow-ecmp] 378 Carpenter, B. and S. Amante, "Using the IPv6 flow label 379 for equal cost multipath routing and link aggregation in 380 tunnels", draft-carpenter-flow-ecmp-03 (work in progress), 381 October 2010. 383 [I-D.gont-6man-flowlabel-security] 384 Gont, F., "Security Assessment of the IPv6 Flow Label", 385 draft-gont-6man-flowlabel-security-01 (work in progress), 386 November 2010. 388 [I-D.hu-flow-label-cases] 389 Hu, Q. and B. Carpenter, "Survey of proposed use cases for 390 the IPv6 flow label", draft-hu-flow-label-cases-02 (work 391 in progress), September 2010. 393 [I-D.martinbeckman-ietf-ipv6-fls-ipv6flowswitching] 394 Beckman, M., "IPv6 Dynamic Flow Label Switching (FLS)", 395 draft-martinbeckman-ietf-ipv6-fls-ipv6flowswitching-03 396 (work in progress), March 2007. 398 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 399 "Definition of the Differentiated Services Field (DS 400 Field) in the IPv4 and IPv6 Headers", RFC 2474, 401 December 1998. 403 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 404 June 1999. 406 [RFC3697] Rajahalme, J., Conta, A., Carpenter, B., and S. Deering, 407 "IPv6 Flow Label Specification", RFC 3697, March 2004. 409 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, 410 December 2005. 412 Appendix A. Alternative Approaches 414 A model was discussed in an earlier version of this document which 415 defined a notion of 'flow label domain' analogous to a differentiated 416 services domain [RFC2474]. This model would have encouraged local 417 usage of the flow label as an alternative to any form of generic use, 418 but it required complex rules for the behaviour of domain boundary 419 routers, and proved controversial in discussion. 421 Two even more complex alternative approaches were also considered and 422 rejected. 424 The first was to distinguish locally significant flow labels from 425 those conforming to RFC 3697 by setting or clearing the most 426 significant bit (MSB) of the flow label. This led to quite 427 complicated rules, seems impossible to make fully self-consistent, 428 and was not considered practical. 430 The second was to use a specific differentiated services code point 431 (DSCP)[RFC2474] in the Traffic Class octet instead of the MSB of the 432 flow label itself, to flag a locally defined behaviour. A more 433 elaborate version of this was proposed in 434 [I-D.martinbeckman-ietf-ipv6-fls-ipv6flowswitching]. There are two 435 issues with this approach. One is that DSCP values are themselves 436 only locally significant, inconsistent with the end-to-end nature of 437 the original flow label definition. Secondly, it seems unwise to 438 meld the semantics of differentiated services, which are currently 439 deployed, with the unknown future semantics of flow label usage. 440 However, this approach, while not recommended, does not appear to 441 violate any basic principles if applied strictly within a single 442 differentiated services domain. 444 Authors' Addresses 446 Shane Amante 447 Level 3 Communications, LLC 448 1025 Eldorado Blvd 449 Broomfield, CO 80021 450 USA 452 Email: shane@level3.net 454 Brian Carpenter 455 Department of Computer Science 456 University of Auckland 457 PB 92019 458 Auckland, 1142 459 New Zealand 461 Email: brian.e.carpenter@gmail.com 463 Sheng Jiang 464 Huawei Technologies Co., Ltd 465 Huawei Building, No.3 Xinxi Rd., 466 Shang-Di Information Industry Base, Hai-Dian District, Beijing 467 P.R. China 469 Email: shengjiang@huawei.com