idnits 2.17.1 draft-carpenter-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 : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC3697, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 291 has weird spacing: '...ding An effic...' (Using the creation date from RFC3697, updated by this document, for RFC5378 checks: 2002-02-28) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (April 13, 2010) is 5117 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- ** 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-01 -- Obsolete informational reference (is this intentional?): RFC 2629 (Obsoleted by RFC 7749) Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group B. Carpenter 3 Internet-Draft Univ. of Auckland 4 Updates: 3697 (if approved) S. Jiang 5 Intended status: Experimental Huawei Technologies Co., Ltd 6 Expires: October 15, 2010 April 13, 2010 8 Update to the IPv6 flow label specification 9 draft-carpenter-6man-flow-update-02 11 Abstract 13 Various uses proposed for the IPv6 flow label are incompatible with 14 its existing specification. This document describes changes to the 15 specification that permit additional use cases as well as allowing 16 continued use of the previous specification. 18 Status of this Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on October 15, 2010. 35 Copyright Notice 37 Copyright (c) 2010 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Normative Notation . . . . . . . . . . . . . . . . . . . . . . 4 54 3. Changes to specification . . . . . . . . . . . . . . . . . . . 4 55 4. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 5 56 5. Security Considerations . . . . . . . . . . . . . . . . . . . 6 57 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 58 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 59 8. Change log . . . . . . . . . . . . . . . . . . . . . . . . . . 7 60 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 61 9.1. Normative References . . . . . . . . . . . . . . . . . . . 7 62 9.2. Informative References . . . . . . . . . . . . . . . . . . 7 63 Appendix A. Alternative Approaches . . . . . . . . . . . . . . . 9 64 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 66 1. Introduction 68 The flow label field in the IPv6 header is reserved but left 69 experimental by [RFC2460] and is specified by [RFC3697]. We quote 70 three rules from that RFC: 71 a. "The Flow Label value set by the source MUST be delivered 72 unchanged to the destination node(s)." 73 b. "IPv6 nodes MUST NOT assume any mathematical or other properties 74 of the Flow Label values assigned by source nodes." 75 c. "Router performance SHOULD NOT be dependent on the distribution 76 of the Flow Label values. Especially, the Flow Label bits alone 77 make poor material for a hash key." 79 The second two rules appear to forbid a usage in which the bits of 80 the flow label are encoded with a specific semantic meaning, or are 81 assumed to have any particular property such as randomness. However, 82 both before and after these rules were laid down, a considerable 83 number of proposals for use of the flow label have been published 84 that seem incompatible with them. Examples are 85 [I-D.conta-ipv6-flow-label], [I-D.conta-diffserv-ipv6-fl-classifier], 86 [I-D.chakravorty-6lsa], [I-D.banerjee-flowlabel-ipv6-qos], 87 [I-D.metzler-ipv6-flowlabel], [LeeKim], [LinTseng], and [Prakash]. 88 These authors propose use cases in which some combination of the 89 following options apply: 90 o The flow label may be changed by intermediate systems. 91 o It doesn't matter if the flow label is changed, because the 92 receiver doesn't use it. 93 o Some or all bits of the flow label are coded: they have specific 94 meanings understood by routers and switches along the path. 95 o The coding is related to the required quality of service, as well 96 as identifying a flow. 97 o The label is used to control forwarding or switching in some way. 99 These proposals all require either some form of encoding of semantics 100 in the bits of the flow label, or the ability for routers to modify 101 the flow label, or both. Thus they appear to infringe the rules from 102 RFC 3697 quoted above. 104 Although [I-D.roberts-inband-qos-ipv6] does not explicitly consider 105 the flow label, it requests hop-by-hop functionality in IPv6 packets 106 very similar to what is needed by the above proposals. 108 We can conclude that a considerable number of researchers and 109 designers are stymied by RFC 3697. On the other hand, proposals such 110 as [I-D.martinbeckman-ietf-ipv6-fls-ipv6flowswitching], 111 [I-D.martinbeckman-ietf-ipv6-amp-ipv6hcamp], 112 [I-D.blake-ipv6-flow-label-nonce], and [I-D.carpenter-flow-ecmp] 113 appear to be compatible with RFC 3697. The latter two are based on 114 the originator of a packet choosing a pseudo-random flow label for 115 each flow. Thus, we can also conclude that there is a useful role 116 for this approach too. The proposal below is intended to resolve 117 this dilemma by allowing both approaches to co-exist. 119 2. Normative Notation 121 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 122 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 123 document are to be interpreted as described in [RFC2119]. 125 3. Changes to specification 127 We note that although RFC 3697 requires the flow label to be 128 delivered unchanged, it is not included in any transport layer 129 pseudo-header checksums nor in IPsec authentication [RFC4302]. We 130 also note that both RFC 2460 and RFC 3697 define the default flow 131 label to be zero. At the time of writing, this is the observed value 132 in an overwhelming proportion of IPv6 packets; neither operating 133 systems nor applications currently set it, and routers do not rely on 134 it. Thus there is no reason to expect operational difficulties if a 135 careful change is made to the rules of RFC 3697. 137 The purpose of the proposed change is that the flow label should be 138 available for domain-specific use, with locally defined semantics, 139 without preventing uses that are compatible with RFC 3697. There 140 should be no impact on specifications other than RFC 3697 and no 141 impact on currently operational software and hardware. 143 The rules of RFC 3697 are modified as follows: 144 1. If and only if the flow label in an IPv6 packet has the default 145 value of zero, then a router MAY set it to a value between 146 between 1 and 0xFFFFF. This option modifies the rule that the 147 flow label must be delivered unchanged, by allowing exactly one 148 router to set it if the source host did not set it. 149 2. If this is done, all packets in a given flow MUST be given the 150 same flow label value. A flow is defined in this case as all 151 packets with the same source and destination IPv6 addresses and 152 port numbers and the same transport protocol number, i.e., the 153 same final Next Header value [RFC2460]. This rule constrains the 154 definition of a flow in RFC 3697 for the specific case that a 155 router sets the flow label. However, it does not constrain the 156 bits of the flow label in any particular way. 157 3. An administratively defined domain containing hosts and routers 158 MAY use a locally defined scheme for the bits of the flow label. 159 This is known as a flow label domain, analogous to a 160 differentiated services domain [RFC2474]. Hosts in such a domain 161 MUST be configured either to set a default (zero) flow label in 162 all IPv6 packets, or to apply the locally defined scheme. When a 163 locally defined scheme is used, packets entering the flow label 164 domain from outside might contain an invalid label according to 165 that scheme. Therefore, border routers MAY treat all packets 166 entering the flow label domain as if they had a default (zero) 167 flow label. This option will be applied in any case where 168 incorrect flow label formats might cause unpredictable behaviour. 169 4. Unless a locally defined scheme for the bits of the flow label is 170 in use, the label, whether set by the source host according to 171 RFC 3697, or by a router according to rules 1 and 2 above, SHOULD 172 contain a pseudo-random value between 1 and 0xFFFFF. The 173 intention of this rule is to encourage load balancing solutions 174 based on using the flow label as input to a hash function, e.g., 175 [I-D.carpenter-flow-ecmp], or to enable behaviour such as defined 176 in [I-D.blake-ipv6-flow-label-nonce]. This recommendation 177 constrains the choice of flow label value more than RFC 3697. 179 The following are the consequences of the above rules combined with 180 those in RFC 3697: 181 o Sending hosts that are not updated will in practice continue to 182 send all-zero labels. If there is no locally defined scheme in 183 use along the path taken by a packet, the label will be delivered 184 unchanged. 185 o Sending hosts wishing to rely only on RFC 3697 behaviour will 186 choose labels between 1 and 0xFFFFF, which should be pseudo-random 187 according to rule 4 above. 188 o Locally defined behaviour of the flow label will be limited to 189 consistent administratively defined domains. 190 o Sending hosts wishing to use locally defined behaviour may 191 continue to send all-zero labels, relying on a router in the local 192 flow label domain to set a value according to rules 1, 2 and 3 193 above. Alternatively, they may set a label according to locally 194 defined rules. 195 o Routers wishing to implement a locally defined behaviour will set 196 a label according to rules 1, 2 and 3 above, if and only if the 197 incoming flow label is all-zero; if the flow label is not all-zero 198 they must not change it, according to rule 1 above. 199 o There is an exception to immutability for border routers of a flow 200 label domain, when external packets arrive with a non-zero flow 201 label. 203 4. Discussion 205 Hosts that set a default (zero) flow label and ignore the flow label 206 on receipt will be unaffected by implementations of this 207 specification. In general, it is assumed that hosts will ignore the 208 flow label on receipt; it cannot be safely used as an end-to-end 209 transport or application layer signal of any kind. 211 Routers that ignore the flow label will be unaffected by 212 implementations of this specification. 214 Hosts that set a default (zero) flow label and are in a flow label 215 domain where routers adopt rules 1, 2, and 3 or 4 in Section 3 will 216 benefit from whatever flow label handling is used in the local 217 domain. Clearly, the rules b and c quoted from RFC 3697 in Section 1 218 have no effect within the local domain, where the locally defined 219 rules (whatever they are) replace them. 221 Hosts and routers that adopt rule 4 by setting a pseudo-random flow 222 label will enhance the performance of any load balancing devices that 223 include the flow label in the hash used to select a particular path 224 or server, even when packets leave the local domain. Again, rules b 225 and c have no effect. 227 If a locally defined flow label scheme is used, so that rule 4 is not 228 implemented, then packets leaving the local domain may contain flow 229 label values that are not pseudo-random. However, because of rule 2, 230 the flow label will still be part of the signature of a single packet 231 flow, so it may still be used as part of a load balancing hash. 232 Rules b and c remain true but do not prevent such usage. To allow 233 for these rules, the load balancing hash function needs to be be 234 designed to allow for a possibly non-random flow label, and traffic 235 containing a non-random flow label might not gain full benefit from 236 load balancing. 238 The rules defined in this document are intended to allow both RFC 239 3697 usage of the flow label in the general case, and a wide variety 240 of locally defined schemes. Such schemes do not need any global 241 assignments of bits in the flow label, and should not have noticeable 242 impact on backwards compatibility or on domains not using them. 244 5. Security Considerations 246 The flow label is not protected in any way and can be forged by an 247 on-path attacker. On the other hand, a pseudo-random flow label 248 cannot be readily guessed by an off-path attacker. See RFC 3697 for 249 further discussion. 251 6. IANA Considerations 253 This document requests no action by IANA. 255 7. Acknowledgements 257 The authors are grateful to Qinwen Hu for general discussion about 258 the flow label and for his work in searching the literature. 259 Valuable comments and contributions were made by Remi Despres, Mark 260 Smith and participants in the 6man working group. 262 This document was produced using the xml2rfc tool [RFC2629]. 264 8. Change log 266 draft-carpenter-6man-flow-update-02: revised and simplified according 267 to WG discussion, 2010-04-13 269 draft-carpenter-6man-flow-update-01: revised according to mail list 270 discussion, 2010-03-05 272 draft-carpenter-6man-flow-update-00: original version, 2010-02-18 274 9. References 276 9.1. Normative References 278 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 279 Requirement Levels", BCP 14, RFC 2119, March 1997. 281 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 282 (IPv6) Specification", RFC 2460, December 1998. 284 [RFC3697] Rajahalme, J., Conta, A., Carpenter, B., and S. Deering, 285 "IPv6 Flow Label Specification", RFC 3697, March 2004. 287 9.2. Informative References 289 [I-D.banerjee-flowlabel-ipv6-qos] 290 Banerjee, R., "A Modified Specification for use of the 291 IPv6 Flow Label for providing An efficient Quality of 292 Service using hybrid approach", 293 draft-banerjee-flowlabel-ipv6-qos-03 (work in progress), 294 April 2002. 296 [I-D.blake-ipv6-flow-label-nonce] 297 Blake, S., "Use of the IPv6 Flow Label as a Transport- 298 Layer Nonce to Defend Against Off-Path Spoofing Attacks", 299 draft-blake-ipv6-flow-label-nonce-02 (work in progress), 300 October 2009. 302 [I-D.carpenter-flow-ecmp] 303 Carpenter, B., "Using the IPv6 flow label for equal cost 304 multipath routing in tunnels", 305 draft-carpenter-flow-ecmp-01 (work in progress), 306 February 2010. 308 [I-D.chakravorty-6lsa] 309 Chakravorty, S., Bush, J., and J. Bound, "IPv6 Label 310 Switching Architecture", draft-chakravorty-6lsa-03 (work 311 in progress), July 2008. 313 [I-D.conta-diffserv-ipv6-fl-classifier] 314 Conta, A. and J. Rajahalme, "Amodel for Diffserv use of 315 the IPv6 Flow Label Specification", 316 draft-conta-diffserv-ipv6-fl-classifier-01 (work in 317 progress), November 2001. 319 [I-D.conta-ipv6-flow-label] 320 Conta, A. and B. Carpenter, "A proposal for the IPv6 Flow 321 Label Specification", draft-conta-ipv6-flow-label-02 (work 322 in progress), July 2001. 324 [I-D.martinbeckman-ietf-ipv6-amp-ipv6hcamp] 325 Beckman, M., "IPv6 Header Compression via Addressing 326 Mitigation Protocol (IPv6 AMP)", 327 draft-martinbeckman-ietf-ipv6-amp-ipv6hcamp-01 (work in 328 progress), March 2007. 330 [I-D.martinbeckman-ietf-ipv6-fls-ipv6flowswitching] 331 Beckman, M., "IPv6 Dynamic Flow Label Switching (FLS)", 332 draft-martinbeckman-ietf-ipv6-fls-ipv6flowswitching-03 333 (work in progress), March 2007. 335 [I-D.metzler-ipv6-flowlabel] 336 Metzler, J. and S. Hauth, "An end-to-end usage of the IPv6 337 flow label", draft-metzler-ipv6-flowlabel-00 (work in 338 progress), November 2000. 340 [I-D.roberts-inband-qos-ipv6] 341 Roberts, L. and J. Harford, "In-Band QoS Signaling for 342 IPv6", draft-roberts-inband-qos-ipv6-00 (work in 343 progress), July 2005. 345 [LeeKim] Lee, I. and S. Kim, "A QoS Improvement Scheme for Real- 346 Time Traffic Using IPv6 Flow Labels", Lecture Notes in 347 Computer Science Vol. 3043, 2004. 349 [LinTseng] 350 Lin, C., Tseng, P., and W. Hwang, "End-to-End QoS 351 Provisioning by Flow Label in IPv6", JCIS , 2006. 353 [Prakash] Prakash, B., "Using the 20 bit flow label field in the 354 IPv6 header to indicate desirable quality of service on 355 the internet", University of Colorado (M.Sc. Thesis), 356 2004. 358 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 359 "Definition of the Differentiated Services Field (DS 360 Field) in the IPv4 and IPv6 Headers", RFC 2474, 361 December 1998. 363 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 364 June 1999. 366 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, 367 December 2005. 369 Appendix A. Alternative Approaches 371 Two more complex alternative approaches were considered and rejected. 373 The first was to distinguish locally significant flow labels from 374 those conforming to RFC 3697 by setting or clearing the most 375 significant bit (MSB) of the flow label. This led to quite 376 complicated rules and was not considered practical. 378 The second was to use a specific differentiated services code point 379 (DSCP)[RFC2474] in the Traffic Class octet instead of the MSB of the 380 flow label itself, to flag a locally defined behaviour. A more 381 elaborate version of this was proposed in 382 [I-D.martinbeckman-ietf-ipv6-fls-ipv6flowswitching]. There are two 383 issues with this approach. One is that DSCP values are themselves 384 only locally significant, inconsistent with the end-to-end nature of 385 the original flow label definition. Secondly, it seems unwise to 386 meld the semantics of differentiated services, which are currently 387 deployed, with the unknown future semantics of flow label usage. 388 However, this approach, while not recommended, does not appear to 389 violate any basic principles if applied strictly within a single 390 differentiated services domain. 392 Authors' Addresses 394 Brian Carpenter 395 Department of Computer Science 396 University of Auckland 397 PB 92019 398 Auckland, 1142 399 New Zealand 401 Email: brian.e.carpenter@gmail.com 403 Sheng Jiang 404 Huawei Technologies Co., Ltd 405 KuiKe Building, No.9 Xinxi Rd., 406 Shang-Di Information Industry Base, Hai-Dian District, Beijing 407 P.R. China 409 Email: shengjiang@huawei.com