idnits 2.17.1 draft-carpenter-6man-flow-update-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) 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 258 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 (February 18, 2010) is 5152 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: 3 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: August 22, 2010 February 18, 2010 8 Update to the IPv6 flow label specification 9 draft-carpenter-6man-flow-update-00 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 to IETF 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), its areas, and its working groups. Note that 25 other groups may also distribute working documents as Internet- 26 Drafts. 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 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/ietf/1id-abstracts.txt. 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html. 39 This Internet-Draft will expire on August 22, 2010. 41 Copyright Notice 43 Copyright (c) 2010 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Normative Notation . . . . . . . . . . . . . . . . . . . . . . 4 60 3. Changes to specification . . . . . . . . . . . . . . . . . . . 4 61 4. Alternative Approach . . . . . . . . . . . . . . . . . . . . . 5 62 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 63 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 64 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 65 8. Change log . . . . . . . . . . . . . . . . . . . . . . . . . . 6 66 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 67 9.1. Normative References . . . . . . . . . . . . . . . . . . . 6 68 9.2. Informative References . . . . . . . . . . . . . . . . . . 7 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 71 1. Introduction 73 The flow label field in the IPv6 header is reserved but left 74 experimental by [RFC2460] and is specified by [RFC3697]. We quote 75 three rules from that RFC: 76 1. "The Flow Label value set by the source MUST be delivered 77 unchanged to the destination node(s)." 78 2. "IPv6 nodes MUST NOT assume any mathematical or other properties 79 of the Flow Label values assigned by source nodes." 80 3. "Router performance SHOULD NOT be dependent on the distribution 81 of the Flow Label values. Especially, the Flow Label bits alone 82 make poor material for a hash key." 84 The second two rules essentially forbid a usage in which the bits of 85 the flow label are encoded with a specific semantic meaning, or are 86 assumed to have any particular property such as randomness. However, 87 both before and after these rules were laid down, a considerable 88 number of proposals for use of the flow label have been published 89 that seem incompatible with them. Examples are 90 [I-D.conta-ipv6-flow-label], [I-D.conta-diffserv-ipv6-fl-classifier], 91 [I-D.chakravorty-6lsa], [I-D.banerjee-flowlabel-ipv6-qos], 92 [I-D.metzler-ipv6-flowlabel], [LeeKim], [LinTseng], and [Prakash]. 93 These authors propose use cases in which some combination of the 94 following options apply: 95 o The flow label may be changed by intermediate systems. 96 o It doesn't matter if the flow label is changed, because the 97 receiver doesn't use it. 98 o Some or all bits of the flow label are coded: they have specific 99 meanings understood by routers and switches along the path. 100 o The coding is related to the required quality of service, as well 101 as identifying a flow. 102 o The label is used to control forwarding or switching in some way. 104 These proposals all require either some form of encoding of semantics 105 in the bits of the flow label, or the ability for routers to modify 106 the flow label, or both. Thus they infringe the rules from RFC 3697 107 quoted above. 109 Although [I-D.roberts-inband-qos-ipv6] does not explicitly consider 110 the flow label, it requests hop-by-hop functionality in IPv6 packets 111 very similar to what is needed by the above proposals. 113 We can conclude that a considerable number of researchers and 114 designers are stymied by RFC 3697. On the other hand, proposals such 115 as [I-D.martinbeckman-ietf-ipv6-fls-ipv6flowswitching], 116 [I-D.martinbeckman-ietf-ipv6-amp-ipv6hcamp], 117 [I-D.blake-ipv6-flow-label-nonce], and [I-D.carpenter-flow-ecmp] 118 appear to be compatible with RFC 3697. The latter two are based on 119 the originator of a packet choosing a pseudo-random flow label for 120 each flow. Thus, we can also conclude that there is a useful role 121 for this approach too. The proposal below is intended to resolve 122 this dilemma by allowing both approaches to co-exist. 124 2. Normative Notation 126 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 127 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 128 document are to be interpreted as described in [RFC2119]. 130 3. Changes to specification 132 We note that although RFC 3697 requires the flow label to be 133 delivered unchanged, it is not included in any transport layer 134 pseudo-header checksums nor in IPsec authentication [RFC4302]. We 135 also note that at the time of writing, the flow label is observed to 136 be set to zero in an overwhelming proportion of IPv6 packets; neither 137 operating systems nor applications currently set it, and routers do 138 not rely on it. Thus there is no reason to expect operational 139 difficulties if a careful change is made to the rules of RFC 3697. 141 The purpose of the proposed change is that some flow label values 142 should be available for domain-specific use, with locally defined 143 semantics, and that other flow label values should be available for 144 uses essentially compatible with RFC 3697. There should be no impact 145 on specifications other than RFC 3697 and no impact on currently 146 operational software and hardware. 148 The proposal is as follows: 149 o If the most significant bit (MSB) of the flow label is 0, then the 150 remaining 19 bits MUST obey the rules of [RFC3697]. (Note that 151 this does not change the meaning of an all-zero flow label or the 152 requirement to deliver it unchanged.) 153 o If the MSB of the flow label is 1, the remaining 19 bits MAY obey 154 a locally defined set of rules and those bits MAY be changed en 155 route. 157 The locally defined set of rules will apply within a given Flow Label 158 Domain, analagous to a Differentiated Services Domain [RFC2474]. A 159 "boundary router" is defined as any router at the boundary between a 160 Flow Label Domain and other parts of the Internet. The following 161 rules define the consequences for compatibility: 162 o Sending hosts that are not updated will in practice continue to 163 send zero labels, which MUST be delivered unchanged. 165 o Sending hosts wishing to rely on RFC 3697 behaviour MUST choose 166 labels with MSB = 0. 167 o Sending hosts wishing to use locally defined behaviour MUST choose 168 labels with MSB = 1 and whatever other rules apply locally. 169 o Receiving hosts that are not updated will continue to ignore 170 labels. 171 o Receiving hosts wishing to rely on RFC 3697 behaviour MUST verify 172 that MSB = 0. 173 o Receiving hosts wishing to use locally defined behaviour MUST 174 verify that MSB = 1. 175 o Routers wishing to implement or rely on locally defined behaviour 176 MUST verify that MSB = 1; if MSB = 0 they MUST NOT change the flow 177 label. 178 o Considering packets outbound from the Flow Label Domain, if MSB = 179 0, a boundary router MUST NOT change the flow label. If MSB = 1, 180 it MUST set all 20 bits of the flow label to zero, so that the 181 locally defined behaviour is not exported from the domain. 182 o Considering packets inbound to the Flow Label Domain, if MSB = 0, 183 a boundary router MUST NOT change the flow label. If an inbound 184 packet has MSB = 1, it has originated from a source not following 185 the current specification. This is considered to be an extremely 186 unlikely case, and the boundary router MUST set all 20 bits of the 187 flow label to zero, as the choice least likely to cause unwanted 188 behaviour. (Note that this means the rules for inbound and 189 outbound packets at the boundary router are identical.) 191 With the ability to define local semantics for 19 bits of the flow 192 label, and the above provisions for compatibility, we add a further 193 recommendation. Its intention is to encourage load balancing 194 solutions based on the flow label, or to enable the behaviour defined 195 in [I-D.blake-ipv6-flow-label-nonce]. 196 o Sending hosts that do not use a locally defined flow label 197 behaviour SHOULD choose flow labels with MSB = 0 followed by a 198 pseudo-random 19 bit number between 1 and 0x7FFFF. 200 4. Alternative Approach 202 Note that an alternative approach would be possible, using a specific 203 differentiated services code point (DSCP)[RFC2474] in the Traffic 204 Class octet instead of the MSB of the flow label itself, to flag a 205 locally defined behaviour. In this model, the above rules would be 206 modified by replacing the condition "MSB = 1" by the condition "DSCP 207 = xxxxxx" (for a specific value xxxxxx) and other fairly 208 straightforward changes. A more elaborate version of this was 209 proposed in [I-D.martinbeckman-ietf-ipv6-fls-ipv6flowswitching]. 210 However, there are two issues with this approach. One is that DSCP 211 values are themselves only locally significant, whereas the 212 specification above makes the MSB a globally signficant flag, 213 consistent with the end-to-end nature of the original flow label 214 definition. Secondly, it seems unwise to meld the semantics of 215 differentiated services, which are currently deployed to some extent, 216 with the unknown future semantics of flow label usage. 218 5. Security Considerations 220 The flow label is not protected in any way and can be forged by an 221 on-path attacker. On the other hand, a pseudo-random flow label 222 cannot be readily guessed by an off-path attacker. See RFC 3697 for 223 further discussion. 225 6. IANA Considerations 227 This document requests no action by IANA. 229 7. Acknowledgements 231 The authors are grateful to Qinwen Hu for general discussion about 232 the flow label and for his work in searching the literature. 233 Valuable comments and contributions were made by ..., and others. 235 This document was produced using the xml2rfc tool [RFC2629]. 237 8. Change log 239 draft-carpenter-6man-flow-update-00: original version, 2010-02-18 241 9. References 243 9.1. Normative References 245 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 246 Requirement Levels", BCP 14, RFC 2119, March 1997. 248 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 249 (IPv6) Specification", RFC 2460, December 1998. 251 [RFC3697] Rajahalme, J., Conta, A., Carpenter, B., and S. Deering, 252 "IPv6 Flow Label Specification", RFC 3697, March 2004. 254 9.2. Informative References 256 [I-D.banerjee-flowlabel-ipv6-qos] 257 Banerjee, R., "A Modified Specification for use of the 258 IPv6 Flow Label for providing An efficient Quality of 259 Service using hybrid approach", 260 draft-banerjee-flowlabel-ipv6-qos-03 (work in progress), 261 April 2002. 263 [I-D.blake-ipv6-flow-label-nonce] 264 Blake, S., "Use of the IPv6 Flow Label as a Transport- 265 Layer Nonce to Defend Against Off-Path Spoofing Attacks", 266 draft-blake-ipv6-flow-label-nonce-02 (work in progress), 267 October 2009. 269 [I-D.carpenter-flow-ecmp] 270 Carpenter, B., "Using the IPv6 flow label for equal cost 271 multipath routing in tunnels", 272 draft-carpenter-flow-ecmp-01 (work in progress), 273 February 2010. 275 [I-D.chakravorty-6lsa] 276 Chakravorty, S., Bush, J., and J. Bound, "IPv6 Label 277 Switching Architecture", draft-chakravorty-6lsa-03 (work 278 in progress), July 2008. 280 [I-D.conta-diffserv-ipv6-fl-classifier] 281 Conta, A. and J. Rajahalme, "Amodel for Diffserv use of 282 the IPv6 Flow Label Specification", 283 draft-conta-diffserv-ipv6-fl-classifier-01 (work in 284 progress), November 2001. 286 [I-D.conta-ipv6-flow-label] 287 Conta, A. and B. Carpenter, "A proposal for the IPv6 Flow 288 Label Specification", draft-conta-ipv6-flow-label-02 (work 289 in progress), July 2001. 291 [I-D.martinbeckman-ietf-ipv6-amp-ipv6hcamp] 292 Beckman, M., "IPv6 Header Compression via Addressing 293 Mitigation Protocol (IPv6 AMP)", 294 draft-martinbeckman-ietf-ipv6-amp-ipv6hcamp-01 (work in 295 progress), March 2007. 297 [I-D.martinbeckman-ietf-ipv6-fls-ipv6flowswitching] 298 Beckman, M., "IPv6 Dynamic Flow Label Switching (FLS)", 299 draft-martinbeckman-ietf-ipv6-fls-ipv6flowswitching-03 300 (work in progress), March 2007. 302 [I-D.metzler-ipv6-flowlabel] 303 Metzler, J. and S. Hauth, "An end-to-end usage of the IPv6 304 flow label", draft-metzler-ipv6-flowlabel-00 (work in 305 progress), November 2000. 307 [I-D.roberts-inband-qos-ipv6] 308 Roberts, L. and J. Harford, "In-Band QoS Signaling for 309 IPv6", draft-roberts-inband-qos-ipv6-00 (work in 310 progress), July 2005. 312 [LeeKim] Lee, I. and S. Kim, "A QoS Improvement Scheme for Real- 313 Time Traffic Using IPv6 Flow Labels", Lecture Notes in 314 Computer Science Vol. 3043, 2004. 316 [LinTseng] 317 Lin, C., Tseng, P., and W. Hwang, "End-to-End QoS 318 Provisioning by Flow Label in IPv6", JCIS , 2006. 320 [Prakash] Prakash, B., "Using the 20 bit flow label field in the 321 IPv6 header to indicate desirable quality of service on 322 the internet", University of Colorado (M.Sc. Thesis), 323 2004. 325 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 326 "Definition of the Differentiated Services Field (DS 327 Field) in the IPv4 and IPv6 Headers", RFC 2474, 328 December 1998. 330 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 331 June 1999. 333 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, 334 December 2005. 336 Authors' Addresses 338 Brian Carpenter 339 Department of Computer Science 340 University of Auckland 341 PB 92019 342 Auckland, 1142 343 New Zealand 345 Email: brian.e.carpenter@gmail.com 346 Sheng Jiang 347 Huawei Technologies Co., Ltd 348 KuiKe Building, No.9 Xinxi Rd., 349 Shang-Di Information Industry Base, Hai-Dian District, Beijing 350 P.R. China 352 Email: shengjiang@huawei.com