idnits 2.17.1 draft-carpenter-6man-flow-update-04.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 date (September 16, 2010) is 4971 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 3697 (Obsoleted by RFC 6437) == Outdated reference: A later version (-03) exists of draft-carpenter-flow-ecmp-02 == Outdated reference: A later version (-03) exists of draft-gont-6man-flowlabel-security-00 == Outdated reference: A later version (-03) exists of draft-hu-flow-label-cases-01 -- Obsolete informational reference (is this intentional?): RFC 2629 (Obsoleted by RFC 7749) Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 2 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: March 20, 2011 Univ. of Auckland 6 S. Jiang 7 Huawei Technologies Co., Ltd 8 September 16, 2010 10 Update to the IPv6 flow label specification 11 draft-carpenter-6man-flow-update-04 13 Abstract 15 Various published proposals for use of the IPv6 flow label are 16 incompatible with its existing 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 proposes changes to the 20 specification in order to clarify it, making it clear what types of 21 usage are possible, and to introduce some 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 March 20, 2011. 40 Copyright Notice 42 Copyright (c) 2010 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. Normative Notation . . . . . . . . . . . . . . . . . . . . . . 6 60 4. Proposed changes to specification . . . . . . . . . . . . . . 6 61 5. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 8 62 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 63 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 64 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 65 9. Change log . . . . . . . . . . . . . . . . . . . . . . . . . . 10 66 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 67 10.1. Normative References . . . . . . . . . . . . . . . . . . 10 68 10.2. Informative References . . . . . . . . . . . . . . . . . 10 69 Appendix A. Alternative Approaches . . . . . . . . . . . . . . . 11 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 72 1. Introduction 74 The flow label field in the IPv6 header was reserved but left 75 experimental by [RFC2460], which mandates only that "Hosts or routers 76 that do not support the functions of the Flow Label field are 77 required to set the field to zero when originating a packet, pass the 78 field on unchanged when forwarding a packet, and ignore the field 79 when receiving a packet." 81 The flow label field was normatively specified by [RFC3697]. In 82 particular, we quote three rules from that RFC: 83 a. "The Flow Label value set by the source MUST be delivered 84 unchanged to the destination node(s)." 85 b. "IPv6 nodes MUST NOT assume any mathematical or other properties 86 of the Flow Label values assigned by source nodes." 87 c. "Router performance SHOULD NOT be dependent on the distribution 88 of the Flow Label values. Especially, the Flow Label bits alone 89 make poor material for a hash key." 91 Additionally, RFC 3697 leaves it undefined what method a host should 92 adopt by default to choose the value of the flow label, if no 93 specific method is in use. It was expected that various signalling 94 methods might be defined for agreeing on values of the flow label, 95 but no such methods have been standardised. 97 RFC 2460 mandates only that "Hosts or routers that do not support the 98 functions of the Flow Label field are required to set the field to 99 zero when originating a packet, pass the field on unchanged when 100 forwarding a packet, and ignore the field when receiving a packet." 102 The flow label is hardly used in practice in existing IPv6 103 implementations. To some extent this is due to the main focus being 104 on basic deployment of IPv6, but the absence of a default method of 105 choosing the flow label value means that most host implementations 106 simply set it to zero. There is also anecdotal evidence that the 107 rules quoted above have led to uncertainty about exactly what is 108 possible. Furthermore, various use cases have been proposed that 109 infringe one or another of the rules. None of these proposals has 110 been accepted as a standard and in practice there is no significant 111 deployment of any mechanism to set the flow label. 113 The intention of this document is to explain this in more detail and 114 to propose changes to RFC 3697 intended to remove the uncertainties 115 and encourage active usage of the flow label. 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 encrypted 136 data. If the flow label were to carry quality of service semantics, 137 then like the diffserv code point [RFC2474], it would not be 138 intrinsically trustworthy across domain boundaries. As a result, 139 some security specialists believe that flow labels should be cleared 140 for safety. These points must be considered when discussing the 141 immutability of 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 such as 190 [I-D.blake-ipv6-flow-label-nonce]. 192 During 2010 there has been considerable debate about these options 193 and variants of them, with a variety of proposals in previous 194 versions of this document and in mailing list discussions. After 195 these discussions, there appears to be a view that simplicity should 196 prevail, and that complicated proposals such as defining quality of 197 service semantics in the flow label, or sub-dividing the flow label 198 field into smaller sub-fields, will not prove efficient or 199 deployable, especially in high speed routers. There is also a 200 clearly expressed view that using the flow label for various forms of 201 stateless load balancing is the best simple application for it. At 202 the same time, it is necessary to recognize that the strict 203 immutability rule has drawbacks as noted above. 205 Even under the rules of RFC 3697, the flow label is intrinsically 206 untrustworthy, because modifcations en route cannot be detected. For 207 this reason, even with the current strict immutability rule, 208 downstream nodes cannot rely on the value being unchanged. In this 209 sense, any use of the flow label must be viewed as an optimisation on 210 a best effort basis; a packet with a changed (or zero) flow label 211 value should never cause a hard failure. 213 The remainder of this document is in the form of a set of proposed 214 modifications to the standard, consistent with the points above and 215 written in normative form. It is suggested that if the proposal is 216 generally accepted, a revised version of RFC 3697 should be produced 217 including these changes. 219 3. Normative Notation 221 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 222 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 223 document are to be interpreted as described in [RFC2119]. 225 4. Proposed changes to specification 227 Although RFC 3697 requires the flow label to be delivered unchanged, 228 as noted above, it is not included in any transport layer pseudo- 229 header checksums nor in IPsec authentication [RFC4302]. Both RFC 230 2460 and RFC 3697 define the default flow label to be zero. At the 231 time of writing, this is the observed value in an overwhelming 232 proportion of IPv6 packets; neither operating systems nor 233 applications currently set it, and routers do not rely on it. Thus 234 there is no reason to expect operational difficulties if a careful 235 change is made to the rules of RFC 3697. 237 In particular, the facts that the label is not checksummed and rarely 238 used mean that the current strict immutability of the label can be 239 moderated without operational consequences. 241 The purposes of the proposed changes are to remove the uncertainties 242 left by RFC 3697, in order to encourage setting of the flow label by 243 default, and to enable its generic use. The proposed generic use is 244 to encourage pseudo-random flow labels that can be used to assist 245 load balancing. There should be no impact on existing IETF 246 specifications other than RFC 3697 and no impact on currently 247 operational software and hardware. 249 A secondary purpose is to modify the immutability of the flow label 250 in a limited way, to allow hosts that do not set the flow label to 251 benefit from it nevertheless. 253 The fact that the flow label may in practice be changed en route is 254 also reflected in the reformulation of the rules. 256 A description of the changes follows. They are written in normative 257 language to avoid ambiguity. They are mainly not written as specific 258 text changes to RFC 3697, and significant rewriting of the latter is 259 needed to incorporate these changes. 261 The definition of a flow is subtly changed from RFC 3697 as follows: 263 A flow is a sequence of packets sent from a particular source to a 264 particular unicast, anycast, or multicast destination that a node 265 desires to label as a flow. A flow could consist of all packets 266 in a specific transport connection or a media stream. However, a 267 flow is not necessarily 1:1 mapped to a transport connection. 269 The change is that the words 'the source' have been replaced by 'a 270 node'. Nodes that do not support the flow label remain subject to 271 RFC 2460. The intention is to enable the following new 272 specifications: 274 1. It is RECOMMENDED that source hosts support the flow label by 275 setting the flow label field for all packets of a flow to the 276 same pseudo-random value. 277 * This rule updates the less precise recommendation made in 278 Section 3 of RFC 3697. Both stateful and stateless methods of 279 assigning a pseudo-random value could be used, but it is 280 outside the scope of this specification to mandate an 281 algorithm. 282 * An OPTIONAL algorithm for generating such a pseudo-random 283 value is proposed in [I-D.gont-6man-flowlabel-security]. 284 * Section 3 of RFC 3697 also allows nodes to participate in an 285 unspecified method of flow state establishment. The changes 286 do not remove that option. 288 2. A node that forwards a flow whose flow label value in arriving 289 packets is zero MAY set the flow label value. In that case, it 290 is RECOMMENDED that the forwarding node sets the flow label field 291 for a flow to a pseudo-random value. 292 * The same considerations apply as to the first recommendation. 293 * This option, if implemented, would presumably be used by 294 ingress routers. It would place a considerable per-packet 295 processing load on them, even if they adopted a stateless 296 method of flow identification and label assignment. This is 297 why the principal recommendation is that the source host 298 should set the label. 300 3. In general, a forwarding node MUST NOT change the flow label 301 value in an arriving packet if it is non-zero. However, there 302 are two qualifications to this rule: 303 1. A forwarding node acting as a domain border device MAY be 304 configured to set the flow label value in incoming packets to 305 the default value of zero. [[Note in draft - this is 306 contentious, but it's going to happen anyway.]] 308 2. A network domain MUST NOT forward packets outside the domain 309 whose flow label values are other than zero or pseudo-random. 311 Note that the new rules above, taken together, allow a given 312 network domain to include routers that set flow labels on behalf 313 of hosts that do not do so, and to be protected at its border (if 314 desired) by clearing flow labels deemed to be untrustworthy. 315 They also require that flow labels exported to the Internet must 316 always be either zero or pseudo-random. These changes replace 317 rule (a) quoted in Section 1. They therefore exclude Internet- 318 wide mechanisms that depend rigidly on immutable flow labels. 319 Given the intrinsic forgeability of the flow label, this seems 320 unavoidable. 322 4. IPv6 nodes MUST NOT assume that the Flow Label value in a 323 incoming packet is identical to the value set by the source node. 324 * This replaces rule (b) quoted in Section 1. 325 * Even though the flow label is in general immutable, this is 326 not guaranteed in real life, hence this rule. See further 327 discussion below. 329 5. Forwarding nodes such as routers and load balancers MUST NOT 330 depend only on Flow Label values being randomly distributed. In 331 any usage such as a hash key for load balancing, the Flow Label 332 bits MUST be combined with bits from other sources within the 333 packet, so as to produce a suitable distribution of hash values. 334 * This replaces rule (c) quoted in Section 1. Although a 335 pseudo-random flow label is recommended, and will always be 336 helpful for load balancing, it is unsafe to assume its 337 presence in the general case, and the use case needs to work 338 even if the flow label value is zero. 340 5. Discussion 342 The following are the consequences of the above changes, taken 343 together with the unaffected parts of RFC 3697: 344 o Sending hosts that are not updated will in practice continue to 345 send all-zero labels. If there is no label-setting router along 346 the path taken by a packet, the label will be delivered as zero. 347 o Sending hosts conforming to this specification will by default 348 choose pseudo-random labels between 1 and 0xFFFFF. 349 o Sending hosts may continue to send all-zero labels, in which case 350 an ingress router may set pseudo-random labels between 1 and 351 0xFFFFF. 352 o Border security devices may clear untrustworthy flow labels. 354 o The flow label is no longer asserted to be strictly immutable. In 355 some circumstances this will break end-to-end usage such as 356 proposed in [I-D.blake-ipv6-flow-label-nonce]. 357 o The expected default usage of the flow label is some form of load 358 balancing, such as the ECMP/LAG usage defined in 359 [I-D.carpenter-flow-ecmp]. 360 o If the rules in Section 4 are followed, especially rule 3.2, all 361 IPv6 traffic flows on the Internet will have zero or pseudo-random 362 flow label values. 364 From an operational viewpoint, existing IPv6 hosts that set a default 365 (zero) flow label value and ignore the flow label on receipt will be 366 unaffected by implementations of this specification. In general, it 367 is assumed that hosts will ignore the value of the flow label on 368 receipt; it cannot be relied on as an end-to-end signal of any kind. 370 Similarly, routers that ignore the flow label will be unaffected by 371 implementations of this specification. 373 Hosts that set a default (zero) flow label and are in a domain where 374 routers adopt the recommended pseudo-random mechanism in Section 4 375 will benefit from whatever flow label handling is used in the local 376 domain. 378 Hosts and routers that adopt the recommended pseudo-random mechanism 379 will enhance the performance of any load balancing devices that 380 include the flow label in the hash used to select a particular path 381 or server, even when packets leave the local domain. 383 6. Security Considerations 385 The flow label is not protected in any way and can be forged by an 386 on-path attacker. On the other hand, a pseudo-random flow label 387 cannot be readily guessed by an off-path attacker. See RFC 3697 and 388 [I-D.gont-6man-flowlabel-security] for further discussion. 390 This proposal recognises that security devices might clear flow label 391 values, if local policy so requires. 393 7. IANA Considerations 395 This document requests no action by IANA. 397 8. Acknowledgements 399 The authors are grateful to Qinwen Hu for general discussion about 400 the flow label and for his work in searching the literature. 401 Valuable comments and contributions were made by Fred Baker, Steve 402 Blake, Remi Despres, Fernando Gont, Brian Haberman, Joel Halpern, 403 Chris Morrow, Thomas Narten, Mark Smith, Pascal Thubert, Iljitsch van 404 Beijnum, and other participants in the 6man working group. 406 This document was produced using the xml2rfc tool [RFC2629]. 408 9. Change log 410 draft-carpenter-6man-flow-update-04: even more simplified according 411 to WG discussion, 2010-09-16 413 draft-carpenter-6man-flow-update-03: futher simplified according to 414 WG discussion, 2010-05-07 416 draft-carpenter-6man-flow-update-02: revised and simplified according 417 to WG discussion, 2010-04-13 419 draft-carpenter-6man-flow-update-01: revised according to mail list 420 discussion, 2010-03-05 422 draft-carpenter-6man-flow-update-00: original version, 2010-02-18 424 10. References 426 10.1. Normative References 428 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 429 Requirement Levels", BCP 14, RFC 2119, March 1997. 431 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 432 (IPv6) Specification", RFC 2460, December 1998. 434 [RFC3697] Rajahalme, J., Conta, A., Carpenter, B., and S. Deering, 435 "IPv6 Flow Label Specification", RFC 3697, March 2004. 437 10.2. Informative References 439 [I-D.blake-ipv6-flow-label-nonce] 440 Blake, S., "Use of the IPv6 Flow Label as a Transport- 441 Layer Nonce to Defend Against Off-Path Spoofing Attacks", 442 draft-blake-ipv6-flow-label-nonce-02 (work in progress), 443 October 2009. 445 [I-D.carpenter-flow-ecmp] 446 Carpenter, B. and S. Amante, "Using the IPv6 flow label 447 for equal cost multipath routing and link aggregation in 448 tunnels", draft-carpenter-flow-ecmp-02 (work in progress), 449 April 2010. 451 [I-D.gont-6man-flowlabel-security] 452 Gont, F., "Security Assessment of the IPv6 Flow Label", 453 draft-gont-6man-flowlabel-security-00 (work in progress), 454 August 2010. 456 [I-D.hu-flow-label-cases] 457 Hu, Q. and B. Carpenter, "Survey of proposed use cases for 458 the IPv6 flow label", draft-hu-flow-label-cases-01 (work 459 in progress), August 2010. 461 [I-D.martinbeckman-ietf-ipv6-fls-ipv6flowswitching] 462 Beckman, M., "IPv6 Dynamic Flow Label Switching (FLS)", 463 draft-martinbeckman-ietf-ipv6-fls-ipv6flowswitching-03 464 (work in progress), March 2007. 466 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 467 "Definition of the Differentiated Services Field (DS 468 Field) in the IPv4 and IPv6 Headers", RFC 2474, 469 December 1998. 471 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 472 June 1999. 474 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, 475 December 2005. 477 Appendix A. Alternative Approaches 479 A model was discussed in an earlier version of this document which 480 defined a notion of 'flow label domain' analogous to a differentiated 481 services domain [RFC2474]. This model would have encouraged local 482 usage of the flow label as an alternative to any form of generic use, 483 but it required complex rules for the behaviour of domain boundary 484 routers, and proved controversial in discussion. 486 Two even more complex alternative approaches were also considered and 487 rejected. 489 The first was to distinguish locally significant flow labels from 490 those conforming to RFC 3697 by setting or clearing the most 491 significant bit (MSB) of the flow label. This led to quite 492 complicated rules, seems impossible to make fully self-consistent, 493 and was not considered practical. 495 The second was to use a specific differentiated services code point 496 (DSCP)[RFC2474] in the Traffic Class octet instead of the MSB of the 497 flow label itself, to flag a locally defined behaviour. A more 498 elaborate version of this was proposed in 499 [I-D.martinbeckman-ietf-ipv6-fls-ipv6flowswitching]. There are two 500 issues with this approach. One is that DSCP values are themselves 501 only locally significant, inconsistent with the end-to-end nature of 502 the original flow label definition. Secondly, it seems unwise to 503 meld the semantics of differentiated services, which are currently 504 deployed, with the unknown future semantics of flow label usage. 505 However, this approach, while not recommended, does not appear to 506 violate any basic principles if applied strictly within a single 507 differentiated services domain. 509 Authors' Addresses 511 Shane Amante 512 Level 3 Communications, LLC 513 1025 Eldorado Blvd 514 Broomfield, CO 80021 515 USA 517 Email: shane@level3.net 519 Brian Carpenter 520 Department of Computer Science 521 University of Auckland 522 PB 92019 523 Auckland, 1142 524 New Zealand 526 Email: brian.e.carpenter@gmail.com 527 Sheng Jiang 528 Huawei Technologies Co., Ltd 529 KuiKe Building, No.9 Xinxi Rd., 530 Shang-Di Information Industry Base, Hai-Dian District, Beijing 531 P.R. China 533 Email: shengjiang@huawei.com