idnits 2.17.1 draft-carpenter-6man-flow-update-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 343 has weird spacing: '...ding An effic...' -- The document date (May 7, 2010) is 5096 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-hu-flow-label-cases-00 -- 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 B. Carpenter 3 Internet-Draft Univ. of Auckland 4 Intended status: Informational S. Jiang 5 Expires: November 8, 2010 Huawei Technologies Co., Ltd 6 May 7, 2010 8 Update to the IPv6 flow label specification 9 draft-carpenter-6man-flow-update-03 11 Abstract 13 Various published proposals for use of the IPv6 flow label are 14 incompatible with its existing specification in RFC 3697. This 15 document proposes changes to the specification that permit additional 16 use cases. The concept of flow label domains is introduced, with the 17 label possibly being rewritten at domain boundaries. 19 Status of this Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on November 8, 2010. 36 Copyright Notice 38 Copyright (c) 2010 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Normative Notation . . . . . . . . . . . . . . . . . . . . . . 4 55 3. Proposed changes to specification . . . . . . . . . . . . . . 4 56 4. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 7 57 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 58 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 59 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 60 8. Change log . . . . . . . . . . . . . . . . . . . . . . . . . . 8 61 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 62 9.1. Normative References . . . . . . . . . . . . . . . . . . . 8 63 9.2. Informative References . . . . . . . . . . . . . . . . . . 8 64 Appendix A. Alternative Approaches . . . . . . . . . . . . . . . 10 65 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 67 1. Introduction 69 The flow label field in the IPv6 header is reserved but left 70 experimental by [RFC2460] and is specified by [RFC3697]. We quote 71 three rules from that RFC: 72 a. "The Flow Label value set by the source MUST be delivered 73 unchanged to the destination node(s)." 74 b. "IPv6 nodes MUST NOT assume any mathematical or other properties 75 of the Flow Label values assigned by source nodes." 76 c. "Router performance SHOULD NOT be dependent on the distribution 77 of the Flow Label values. Especially, the Flow Label bits alone 78 make poor material for a hash key." 80 The second rule appears to forbid a usage in which the bits of the 81 flow label are encoded with a specific semantic meaning. If the word 82 "alone" is overlooked, the third rule has sometimes been interpreted 83 to forbid the use of the flow label by load balancing mechansims. 84 However, both before and after these rules were laid down, a 85 considerable number of proposals for use of the flow label have been 86 published that seem incompatible with them. An analysis is presented 87 in [I-D.hu-flow-label-cases], and examples are 88 [I-D.conta-ipv6-flow-label], [I-D.conta-diffserv-ipv6-fl-classifier], 89 [I-D.chakravorty-6lsa], [I-D.banerjee-flowlabel-ipv6-qos], 90 [I-D.metzler-ipv6-flowlabel], [LeeKim], [LinTseng], and [Prakash]. 91 These authors propose use cases in which some combination of the 92 following options apply: 93 o The flow label may be changed by intermediate systems. 94 o It doesn't matter if the flow label is changed, because the 95 receiver doesn't use it. 96 o Some or all bits of the flow label are coded: they have specific 97 meanings understood by routers and switches along the path. 98 o The coding is related to the required quality of service, as well 99 as identifying a flow. 100 o The label is used to control forwarding or switching in some way. 102 These proposals all require either some form of encoding of semantics 103 in the bits of the flow label, or the ability for routers to modify 104 the flow label, or both. Thus they appear to infringe the rules from 105 RFC 3697 quoted above. 107 Although [I-D.roberts-inband-qos-ipv6] does not explicitly consider 108 the flow label, it requests hop-by-hop functionality in IPv6 packets 109 very similar to what is needed by the above proposals. 111 We can conclude that a considerable number of researchers and 112 designers are stymied by RFC 3697. On the other hand, proposals such 113 as [I-D.martinbeckman-ietf-ipv6-fls-ipv6flowswitching], 114 [I-D.martinbeckman-ietf-ipv6-amp-ipv6hcamp], 116 [I-D.blake-ipv6-flow-label-nonce], and [I-D.carpenter-flow-ecmp] 117 appear to be compatible with RFC 3697. The latter two are based on 118 the originator of a packet choosing a pseudo-random flow label for 119 each flow. Thus, we can also conclude that there is a useful role 120 for this approach too. 122 If our goal is for the flow label to be used in practice, the 123 conflict between these two approaches creates a dilemma. There 124 appear to be two viable approaches: 125 1. Definitively forbid locally defined use of the flow label. 126 Strengthen RFC 3697 to say that hosts SHOULD set a pseudo-random 127 label value, which would clarify and limit its possible uses. In 128 particular, its use for load balancing and possibly as a nonce 129 would be encouraged. 130 2. Encourage locally defined use of the flow label. This approach 131 would make the flow label mutable and would exclude any use case 132 depending on end-to-end immutability. It would encourage 133 applications of a pseudo-random flow label, such as load 134 balancing, on a local basis, but it would exclude end-to-end 135 applications such as [I-D.blake-ipv6-flow-label-nonce]. 137 This document is in the form of a set of proposed modifications to 138 the standard, expressing approach 2 and written in normative form. 139 It is suggested that if the proposal is generally accepted, a revised 140 version of RFC 3697 should be produced including these changes. 141 Alternatively, a much simpler revision to express approach 1 above 142 could be chosen. 144 2. Normative Notation 146 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 147 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 148 document are to be interpreted as described in [RFC2119]. 150 3. Proposed changes to specification 152 Although RFC 3697 requires the flow label to be delivered unchanged, 153 it is not included in any transport layer pseudo-header checksums nor 154 in IPsec authentication [RFC4302]. Both RFC 2460 and RFC 3697 define 155 the default flow label to be zero. At the time of writing, this is 156 the observed value in an overwhelming proportion of IPv6 packets; 157 neither operating systems nor applications currently set it, and 158 routers do not rely on it. Thus there is no reason to expect 159 operational difficulties if a careful change is made to the rules of 160 RFC 3697. 162 In particular, the facts that the label is not checksummed and not 163 used mean that the current immutability of the label can be changed 164 without any operational consequences. 166 The purpose of the proposed change is that the flow label should be 167 available for domain-specific use, with locally defined semantics, 168 without preventing a default type of generic usage. The proposed 169 generic usage is to enourage pseudo-random flow labels that can be 170 used to assist load balancing. There should be no impact on 171 specifications other than RFC 3697 and no impact on currently 172 operational software and hardware. 174 Firstly we define a "Flow Label Domain" by direct analogy with a 175 Differentiated Services Domain [RFC2474]: 176 Flow Label Domain (also FL domain): a contiguous portion of the 177 Internet over which a consistent scheme of flow label mechanisms 178 is administered in a coordinated fashion. A flow label domain can 179 represent different administrative domains or autonomous systems, 180 different trust regions, different network layer technologies, 181 hosts and routers, etc. 182 Flow Label Boundary (also FL boundary): the edge of an FL domain. 183 A flow label boundary can be further sub-divided into ingress and 184 egress nodes, where the ingress/egress nodes are the downstream/ 185 upstream nodes of a boundary link in a given traffic direction. A 186 flow label boundary is typically found at the ingress to the 187 first-hop flow label router (or network node) that a host's 188 packets traverse, or at the egress of the last-hop flow label 189 router (or network node) that packets traverse before arriving at 190 a host. A flow label boundary may be co-located with a host, 191 subject to local policy. 192 Flow Label Router (also FL router): a router that sets or 193 interprets the flow label according to the mechanisms used in a 194 given FL domain. 196 The rules of RFC 3697 are modified as follows: 197 1. An FL domain implements a local scheme of flow label mechanisms. 198 The RECOMMENDED scheme is that, whether set by the source host 199 according to RFC 3697, or by an FL router according to the rules 200 below, the label contains a pseudo-random value between 1 and 201 0xFFFFF. This recommendation constrains the choice of flow label 202 value more than RFC 3697. An FL domain MAY define an alternative 203 scheme. 204 2. If and only if the flow label in an IPv6 packet has the default 205 value of zero, then an FL router MAY set it to a value between 206 between 1 and 0xFFFFF. This option modifies the rule that the 207 flow label must be delivered unchanged, by allowing a router in 208 an FL domain to set it if the source host did not set it. 210 3. If this is done, all packets in a given flow MUST be given the 211 same flow label value. A flow is defined in this case as all 212 packets with the same source and destination IPv6 addresses and 213 port numbers and the same transport protocol number, i.e., the 214 same final Next Header value [RFC2460]. This rule constrains the 215 definition of a flow in RFC 3697 for the specific case that a 216 router sets the flow label. It should be noted that an FL router 217 applying this rule will be obliged to inspect the IPv6 header of 218 every packet, including finding the last "next header" field in 219 the packet, at full line speed. 220 4. Hosts connected to an FL domain MUST be configured either to set 221 a default (zero) flow label in all IPv6 packets, or to apply the 222 locally defined scheme (which, by rule 1, SHOULD be the pseudo- 223 random scheme). 224 5. When a locally defined scheme other than the pseudo-random scheme 225 is used, packets entering the FL domain from outside might 226 contain an invalid label according to that scheme. Therefore, 227 boundary ingress FL routers MUST treat all packets entering such 228 an FL domain as if they had a default (zero) flow label. 229 6. When a locally defined scheme other than the pseudo-random scheme 230 is used, packets leaving the FL domain might contain a label that 231 would be misinterpreted elsewhere. Therefore, the boundary 232 egress FL router SHOULD set the label according to the pseudo- 233 random mechanism defined in rule 1. If not, it MUST set the 234 label to the default value of zero. 236 The following are the consequences of the above rules combined with 237 those in RFC 3697: 238 o Sending hosts that are not updated will in practice continue to 239 send all-zero labels. If there is no locally defined scheme in 240 use along the path taken by a packet, the label will be delivered 241 as zero. 242 o Sending hosts conforming to this specification will by default 243 choose pseudo-random labels between 1 and 0xFFFFF. 244 o Locally defined behaviour of the flow label will be limited to 245 consistent administratively defined domains. 246 o Sending hosts wishing to use locally defined behaviour may 247 continue to send all-zero labels, relying on a router in the local 248 flow label domain to set a value according to the rules above. 249 Alternatively, they may set a label according to locally defined 250 rules. 251 o Routers wishing to implement a locally defined behaviour will set 252 a label according to the rules above, if and only if the incoming 253 flow label is all-zero, according to rule 1 above. 254 o The flow label is no longer immutable if it crosses a FL domain 255 boundary. This will allow a wide range of uses cases previously 256 forbidden, and will allow the ECMP/LAG usage defined in 257 [I-D.carpenter-flow-ecmp]. However, it will break the usage 258 proposed in [I-D.blake-ipv6-flow-label-nonce]. 260 4. Discussion 262 Hosts that set a default (zero) flow label and ignore the flow label 263 on receipt will be unaffected by implementations of this 264 specification. In general, it is assumed that hosts will ignore the 265 flow label on receipt; it cannot be safely used as an end-to-end 266 transport or application layer signal of any kind. 268 Routers that ignore the flow label will be unaffected by 269 implementations of this specification. 271 Hosts that set a default (zero) flow label and are in an FL domain 272 where routers adopt a locally defined scheme, or the pseudo-random 273 mechanism in Section 3, will benefit from whatever flow label 274 handling is used in the local domain. Clearly, the rules b and c 275 quoted from RFC 3697 in Section 1 have no effect within the local 276 domain, where the locally defined rules (whatever they are) replace 277 them. 279 Hosts and routers that adopt the pseudo-random mechanism will enhance 280 the performance of any load balancing devices that include the flow 281 label in the hash used to select a particular path or server, even 282 when packets leave the local FL domain. Again, rules b and c have no 283 effect. 285 The rules defined in this proposal are intended to allow encourage 286 the adoption of pseudo-random flow labels in the general case, but 287 also allow a wide variety of locally defined schemes. Such schemes 288 do not need any global assignments of bits in the flow label, and 289 should not have noticeable impact on backwards compatibility or on 290 domains not using them. 292 5. Security Considerations 294 The flow label is not protected in any way and can be forged by an 295 on-path attacker. On the other hand, a pseudo-random flow label 296 cannot be readily guessed by an off-path attacker. See RFC 3697 for 297 further discussion. 299 6. IANA Considerations 301 This document requests no action by IANA. 303 7. Acknowledgements 305 The authors are grateful to Qinwen Hu for general discussion about 306 the flow label and for his work in searching the literature. 307 Valuable comments and contributions were made by Shane Amante, Fred 308 Baker, Steve Blake, Remi Despres, Joel Halpern, Chris Morrow, Mark 309 Smith, and other participants in the 6man working group. 311 This document was produced using the xml2rfc tool [RFC2629]. 313 8. Change log 315 draft-carpenter-6man-flow-update-03: futher simplified according to 316 WG discussion, 2010-05-07 318 draft-carpenter-6man-flow-update-02: revised and simplified according 319 to WG discussion, 2010-04-13 321 draft-carpenter-6man-flow-update-01: revised according to mail list 322 discussion, 2010-03-05 324 draft-carpenter-6man-flow-update-00: original version, 2010-02-18 326 9. References 328 9.1. Normative References 330 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 331 Requirement Levels", BCP 14, RFC 2119, March 1997. 333 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 334 (IPv6) Specification", RFC 2460, December 1998. 336 [RFC3697] Rajahalme, J., Conta, A., Carpenter, B., and S. Deering, 337 "IPv6 Flow Label Specification", RFC 3697, March 2004. 339 9.2. Informative References 341 [I-D.banerjee-flowlabel-ipv6-qos] 342 Banerjee, R., "A Modified Specification for use of the 343 IPv6 Flow Label for providing An efficient Quality of 344 Service using hybrid approach", 345 draft-banerjee-flowlabel-ipv6-qos-03 (work in progress), 346 April 2002. 348 [I-D.blake-ipv6-flow-label-nonce] 349 Blake, S., "Use of the IPv6 Flow Label as a Transport- 350 Layer Nonce to Defend Against Off-Path Spoofing Attacks", 351 draft-blake-ipv6-flow-label-nonce-02 (work in progress), 352 October 2009. 354 [I-D.carpenter-flow-ecmp] 355 Carpenter, B. and S. Amante, "Using the IPv6 flow label 356 for equal cost multipath routing and link aggregation in 357 tunnels", draft-carpenter-flow-ecmp-02 (work in progress), 358 April 2010. 360 [I-D.chakravorty-6lsa] 361 Chakravorty, S., Bush, J., and J. Bound, "IPv6 Label 362 Switching Architecture", draft-chakravorty-6lsa-03 (work 363 in progress), July 2008. 365 [I-D.conta-diffserv-ipv6-fl-classifier] 366 Conta, A. and J. Rajahalme, "Amodel for Diffserv use of 367 the IPv6 Flow Label Specification", 368 draft-conta-diffserv-ipv6-fl-classifier-01 (work in 369 progress), November 2001. 371 [I-D.conta-ipv6-flow-label] 372 Conta, A. and B. Carpenter, "A proposal for the IPv6 Flow 373 Label Specification", draft-conta-ipv6-flow-label-02 (work 374 in progress), July 2001. 376 [I-D.hu-flow-label-cases] 377 Hu, Q. and B. Carpenter, "Survey of proposed use cases for 378 the IPv6 flow label", draft-hu-flow-label-cases-00 (work 379 in progress), April 2010. 381 [I-D.martinbeckman-ietf-ipv6-amp-ipv6hcamp] 382 Beckman, M., "IPv6 Header Compression via Addressing 383 Mitigation Protocol (IPv6 AMP)", 384 draft-martinbeckman-ietf-ipv6-amp-ipv6hcamp-01 (work in 385 progress), March 2007. 387 [I-D.martinbeckman-ietf-ipv6-fls-ipv6flowswitching] 388 Beckman, M., "IPv6 Dynamic Flow Label Switching (FLS)", 389 draft-martinbeckman-ietf-ipv6-fls-ipv6flowswitching-03 390 (work in progress), March 2007. 392 [I-D.metzler-ipv6-flowlabel] 393 Metzler, J. and S. Hauth, "An end-to-end usage of the IPv6 394 flow label", draft-metzler-ipv6-flowlabel-00 (work in 395 progress), November 2000. 397 [I-D.roberts-inband-qos-ipv6] 398 Roberts, L. and J. Harford, "In-Band QoS Signaling for 399 IPv6", draft-roberts-inband-qos-ipv6-00 (work in 400 progress), July 2005. 402 [LeeKim] Lee, I. and S. Kim, "A QoS Improvement Scheme for Real- 403 Time Traffic Using IPv6 Flow Labels", Lecture Notes in 404 Computer Science Vol. 3043, 2004. 406 [LinTseng] 407 Lin, C., Tseng, P., and W. Hwang, "End-to-End QoS 408 Provisioning by Flow Label in IPv6", JCIS , 2006. 410 [Prakash] Prakash, B., "Using the 20 bit flow label field in the 411 IPv6 header to indicate desirable quality of service on 412 the internet", University of Colorado (M.Sc. Thesis), 413 2004. 415 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 416 "Definition of the Differentiated Services Field (DS 417 Field) in the IPv4 and IPv6 Headers", RFC 2474, 418 December 1998. 420 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 421 June 1999. 423 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, 424 December 2005. 426 Appendix A. Alternative Approaches 428 Two more complex alternative approaches were considered and rejected. 430 The first was to distinguish locally significant flow labels from 431 those conforming to RFC 3697 by setting or clearing the most 432 significant bit (MSB) of the flow label. This led to quite 433 complicated rules, seems impossible to make fully self-consistent, 434 and was not considered practical. 436 The second was to use a specific differentiated services code point 437 (DSCP)[RFC2474] in the Traffic Class octet instead of the MSB of the 438 flow label itself, to flag a locally defined behaviour. A more 439 elaborate version of this was proposed in 440 [I-D.martinbeckman-ietf-ipv6-fls-ipv6flowswitching]. There are two 441 issues with this approach. One is that DSCP values are themselves 442 only locally significant, inconsistent with the end-to-end nature of 443 the original flow label definition. Secondly, it seems unwise to 444 meld the semantics of differentiated services, which are currently 445 deployed, with the unknown future semantics of flow label usage. 446 However, this approach, while not recommended, does not appear to 447 violate any basic principles if applied strictly within a single 448 differentiated services domain that is also a flow label domain. 450 Authors' Addresses 452 Brian Carpenter 453 Department of Computer Science 454 University of Auckland 455 PB 92019 456 Auckland, 1142 457 New Zealand 459 Email: brian.e.carpenter@gmail.com 461 Sheng Jiang 462 Huawei Technologies Co., Ltd 463 KuiKe Building, No.9 Xinxi Rd., 464 Shang-Di Information Industry Base, Hai-Dian District, Beijing 465 P.R. China 467 Email: shengjiang@huawei.com