idnits 2.17.1 draft-ietf-6man-flow-3697bis-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 : ---------------------------------------------------------------------------- -- The draft header indicates that this document obsoletes RFC3697, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC2460, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC2205, 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 == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. (Using the creation date from RFC2205, updated by this document, for RFC5378 checks: 1997-09-01) (Using the creation date from RFC2460, updated by this document, for RFC5378 checks: 1997-07-30) -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (May 11, 2011) is 4706 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** 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 (-07) exists of draft-ietf-6man-flow-update-05 -- 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 (~~), 4 warnings (==), 7 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 Obsoletes: 3697 (if approved) B. Carpenter 5 Updates: 2205, 2460 (if approved) Univ. of Auckland 6 Intended status: Standards Track S. Jiang 7 Expires: November 12, 2011 Huawei Technologies Co., Ltd 8 J. Rajahalme 9 Nokia Siemens Networks 10 May 11, 2011 12 IPv6 Flow Label Specification 13 draft-ietf-6man-flow-3697bis-04 15 Abstract 17 This document specifies the IPv6 Flow Label field and the minimum 18 requirements for IPv6 nodes labeling flows, IPv6 nodes forwarding 19 labeled packets, and flow state establishment methods. Even when 20 mentioned as examples of possible uses of the flow labeling, more 21 detailed requirements for specific use cases are out of scope for 22 this document. 24 The usage of the Flow Label field enables efficient IPv6 flow 25 classification based only on IPv6 main header fields in fixed 26 positions. 28 Status of this Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on November 12, 2011. 45 Copyright Notice 47 Copyright (c) 2011 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 This document may contain material from IETF Documents or IETF 61 Contributions published or made publicly available before November 62 10, 2008. The person(s) controlling the copyright in some of this 63 material may not have granted the IETF Trust the right to allow 64 modifications of such material outside the IETF Standards Process. 65 Without obtaining an adequate license from the person(s) controlling 66 the copyright in such materials, this document may not be modified 67 outside the IETF Standards Process, and derivative works of it may 68 not be created outside the IETF Standards Process, except to format 69 it for publication as an RFC or to translate it into languages other 70 than English. 72 Table of Contents 74 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 75 2. IPv6 Flow Label Specification . . . . . . . . . . . . . . . . 5 76 3. Flow Labeling Requirements in the Stateless Scenario . . . . . 6 77 4. Flow State Establishment Requirements . . . . . . . . . . . . 8 78 5. Essential correction to RFC 2205 . . . . . . . . . . . . . . . 8 79 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 80 6.1. Covert Channel Risk . . . . . . . . . . . . . . . . . . . 8 81 6.2. Theft and Denial of Service . . . . . . . . . . . . . . . 9 82 6.3. IPsec and Tunneling Interactions . . . . . . . . . . . . . 10 83 6.4. Security Filtering Interactions . . . . . . . . . . . . . 11 84 7. Differences from RFC 3697 . . . . . . . . . . . . . . . . . . 11 85 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 86 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 87 10. Change log [RFC Editor: Please remove] . . . . . . . . . . . . 12 88 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 89 11.1. Normative References . . . . . . . . . . . . . . . . . . . 13 90 11.2. Informative References . . . . . . . . . . . . . . . . . . 13 91 Appendix A. Simple 20-bit Hash Function . . . . . . . . . . . . . 14 92 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 94 1. Introduction 96 From the viewpoint of the network layer, a flow is a sequence of 97 packets sent from a particular source to a particular unicast, 98 anycast, or multicast destination that a node desires to label as a 99 flow. From an upper layer viewpoint, a flow could consist of all 100 packets in a specific transport connection or a media stream. 101 However, a flow is not necessarily 1:1 mapped to a transport 102 connection. 104 Traditionally, flow classifiers have been based on the 5-tuple of the 105 source and destination addresses, ports, and the transport protocol 106 type. However, some of these fields may be unavailable due to either 107 fragmentation or encryption, or locating them past a chain of IPv6 108 extension headers may be inefficient. Additionally, if classifiers 109 depend only on IP layer headers, later introduction of alternative 110 transport layer protocols will be easier. 112 The usage of the 3-tuple of the Flow Label and the Source and 113 Destination Address fields enables efficient IPv6 flow 114 classification, where only IPv6 main header fields in fixed positions 115 are used. 117 The flow label could be used in both stateless and stateful 118 scenarios. A stateless scenario is one where any node that processes 119 the flow label in any way does not need to store any information 120 about a flow before or after a packet has been processed. A stateful 121 scenario is one where a node that processes the flow label value 122 needs to store information about the flow, including the flow label 123 value. A stateful scenario might also require a signaling mechanism 124 to establish flow state in the network. 126 The flow label can be used most simply in stateless scenarios. This 127 specification concentrates on the stateless model and how it can be 128 used as a default mechanism. Details of stateful models, signaling, 129 specific flow state establishment methods and their related service 130 models are out of scope for this specification. The basic 131 requirement for stateful models is set forth in Section 4. 133 The minimum level of IPv6 flow support consists of labeling the 134 flows. A specific goal is to enable and encourage the use of the 135 flow label for various forms of stateless load distribution, 136 especially across Equal Cost Multi-Path (EMCP) and/or Link 137 Aggregation Group (LAG) paths. ECMP and LAG are methods to bond 138 together multiple physical links used to procure the required 139 capacity necessary to carry an offered load greater than the 140 bandwidth of an individual physical link. IPv6 source nodes SHOULD 141 be able to label known flows (e.g., TCP connections, application 142 streams), even if the node itself does not require any flow-specific 143 treatment. Node requirements for stateless flow labeling are given 144 in Section 3. 146 This document replaces [RFC3697] and Section 6 and Appendix A of 147 [RFC2460]. A rationale for the changes made is documented in 148 [I-D.ietf-6man-flow-update]. The present document also includes a 149 correction to [RFC2205] concerning the flow label. 151 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 152 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 153 document are to be interpreted as described in [RFC2119]. 155 2. IPv6 Flow Label Specification 157 The 20-bit Flow Label field in the IPv6 header [RFC2460] is used by a 158 node to label packets of a flow. A Flow Label of zero is used to 159 indicate packets that have not been labeled. Packet classifiers can 160 use the triplet of Flow Label, Source Address, and Destination 161 Address fields to identify which flow a particular packet belongs to. 162 Packets are processed in a flow-specific manner by nodes that are 163 able to do so in a stateless manner, or that have been set up with 164 flow-specific state. The nature of the specific treatment and the 165 methods for flow state establishment are out of scope for this 166 specification. 168 Flow label values should be chosen such that their bits exhibit a 169 high degree of variability, making them suitable for use as part of 170 the input to a hash function used in a load distribution scheme. At 171 the same time, third parties should be unlikely to be able to guess 172 the next value that a source of flow labels will choose. 174 In statistics, a discrete uniform distribution is defined as a 175 probability distribution in which each value in a given range of 176 equally spaced values (such as a sequence of integers) is equally 177 likely to be chosen as the next value. The values in such a 178 distribution exhibit both variability and unguessability. Thus, as 179 specified below in Section 3, an approximation to a discrete uniform 180 distribution is preferable as the source of flow label values. 181 Intentionally, there are no precise mathematical requirements placed 182 on the distribution or the method used to achieve such a 183 distribution. 185 Once set to a non-zero value, the Flow Label MUST be delivered 186 unchanged to the destination node(s). That is, a forwarding node 187 MUST NOT change the flow label value in an arriving packet if it is 188 non-zero. A possible exception to this rule is if a security gateway 189 for operational security reasons changes a non-zero Flow Label value 190 to a different non-zero value compliant with this RFC; see 191 Section 6.1 for details. 193 There is no way to verify whether a flow label has been modified en 194 route or whether it belongs to a uniform distribution. Therefore, no 195 Internet-wide mechanism can depend mathematically on unmodified and 196 uniformly distributed flow labels; they have a "best effort" quality. 197 Implementers should be aware that the flow label is an unprotected 198 field that could have been accidentally or intentionally changed en 199 route (see Section 6). This leads to the following formal rule: 200 o Forwarding nodes such as routers and load distributors MUST NOT 201 depend only on Flow Label values being uniformly distributed. In 202 any usage such as a hash key for load distribution, the Flow Label 203 bits MUST be combined at least with bits from other sources within 204 the packet, so as to produce a constant hash value for each flow 205 and a suitable distribution of hash values across flows. 206 Typically the other fields used will be some or all components of 207 the usual 5-tuple. In this way, load distribution will still 208 occur even if the Flow Label values are poorly distributed. 210 Although uniformly distributed flow label values are recommended 211 below, and will always be helpful for load distribution, it is unsafe 212 to assume their presence in the general case, and the use case needs 213 to work even if the flow label value is zero. 215 As a general practice, packet flows should not be reordered, and the 216 use of the Flow Label field does not affect this. In particular, a 217 Flow label value of zero does not imply that reordering is 218 acceptable. 220 3. Flow Labeling Requirements in the Stateless Scenario 222 This section defines the minimum requirements for methods of setting 223 the flow label value within the stateless scenario of flow label 224 usage. 226 To enable Flow Label based classification, source nodes SHOULD assign 227 each unrelated transport connection and application data stream to a 228 new flow. A typical definition of a flow for this purpose is any set 229 of packets carrying the same 5-tuple {dest addr, source addr, 230 protocol, dest port, source port}. 232 It is desirable that flow label values should be uniformly 233 distributed to assist load distribution. It is therefore RECOMMENDED 234 that source hosts support the flow label by setting the flow label 235 field for all packets of a given flow to the same value chosen from 236 an approximation to a discrete uniform distribution. Both stateful 237 and stateless methods of assigning a value could be used, but it is 238 outside the scope of this specification to mandate an algorithm. The 239 algorithm SHOULD ensure that the resulting flow label values are 240 unique with high probability. However, if two simultaneous flows are 241 by chance assigned the same flow label value, and have the same 242 source and destination addresses, it simply means that they will 243 receive the same treatment throughout the network. As long as this 244 is a low probability event, it will not significantly affect load 245 distribution. 247 A possible stateless algorithm is to use a suitable 20 bit hash of 248 values from the IP packet's 5-tuple. A simple hash function is 249 described in Appendix A. 251 An alternative approach is to to use a pseudo-random number generator 252 to assign a flow label value for a given transport session; such a 253 method will require minimal local state to be kept at the source 254 node, by recording the flow label associated with each transport 255 socket. 257 Viewed externally, either of these approaches will produce values 258 that appear to be uniformly distributed and pseudo-random. 260 An implementation in which flow labels are assigned sequentially is 261 NOT RECOMMENDED, as it would then be simple for on-path observers to 262 guess the next value. 264 A source node which does not otherwise set the flow label MUST set 265 its value to zero. 267 A node that forwards a flow whose flow label value in arriving 268 packets is zero MAY change the flow label value. In that case, it is 269 RECOMMENDED that the forwarding node sets the flow label field for a 270 flow to a uniformly distributed value as just described for source 271 nodes. 272 o The same considerations apply as to source hosts setting the flow 273 label; in particular, the normal case is that a flow is defined by 274 the 5-tuple. 275 o This option, if implemented, would presumably be used by first-hop 276 or ingress routers. It might place a considerable per-packet 277 processing load on them, even if they adopted a stateless method 278 of flow identification and label assignment. This is why the 279 principal recommendation is that the source host should set the 280 label. 282 The preceding rules taken together allow a given network to include 283 routers that set flow labels on behalf of hosts that do not do so. 285 They also recommend that flow labels exported to the Internet are 286 always either zero or uniformly distributed. 288 4. Flow State Establishment Requirements 290 A node that sets the flow label MAY also take part in a flow state 291 establishment method that results in assigning specific treatments to 292 specific flows, possibly including signaling. Any such method MUST 293 NOT disturb nodes taking part in the stateless scenario just 294 described. Thus, any node that sets flow label values according to a 295 stateful scheme MUST choose labels that conform to Section 3 of the 296 present specification. Further details are not discussed in this 297 document. 299 5. Essential correction to RFC 2205 301 [RFC2460] reduced the size of the flow label field from 24 to 20 302 bits. The references to a 24 bit flow label field on pages 87 and 88 303 of [RFC2205] are updated accordingly. 305 6. Security Considerations 307 This section considers security issues raised by the use of the Flow 308 Label, including the potential for denial-of-service attacks, and the 309 related potential for theft of service by unauthorized traffic 310 (Section 6.2). Section 6.3 addresses the use of the Flow Label in 311 the presence of IPsec including its interaction with IPsec tunnel 312 mode and other tunneling protocols. We also note that inspection of 313 unencrypted Flow Labels may allow some forms of traffic analysis by 314 revealing some structure of the underlying communications. Even if 315 the flow label were encrypted, its presence as a constant value in a 316 fixed position might assist traffic analysis and cryptoanalysis. 318 The flow label is not protected in any way, even if IPsec 319 authentication [RFC4302] is in use, so it can be forged by an on-path 320 attacker. Implementers are advised that any en-route change to the 321 flow label value is undetectable. On the other hand, a uniformly 322 distributed pseudo-random flow label cannot be readily guessed by an 323 attacker; see [I-D.gont-6man-flowlabel-security] for further 324 discussion. 326 6.1. Covert Channel Risk 328 The flow label could be used as a covert data channel, since 329 apparently pseudo-random flow label values could in fact consist of 330 covert data. This could for example be achieved using a series of 331 otherwise innocuous UDP packets whose flow label values constitute a 332 covert message, or by co-opting a TCP session to carry a covert 333 message in the flow labels of successive packets. Both of these 334 could be recognised as suspicious - the first because isolated UDP 335 packets would not normally be expected to have non-zero flow labels, 336 and the second because the flow label values in a given TCP session 337 should all be equal. However, other methods, such as co-opting the 338 flow labels of occasional packets, might be rather hard to detect. 340 In situations where the covert channel risk is considered 341 significant, the only certain defense is for a firewall to rewrite 342 non-zero flow labels in a stateless manner, like a first-hop router 343 (see Section 3). This would be an exceptional violation of the rule 344 that the flow label, once set to a non-zero value, must not be 345 changed. To preserve load distribution capability, such a firewall 346 MUST NOT set non-zero flow labels to zero. 348 6.2. Theft and Denial of Service 350 Since the mapping of network traffic to flow-specific treatment is 351 triggered by the IP addresses and Flow Label value of the IPv6 352 header, an adversary may be able to obtain unintended service by 353 modifying the IPv6 header or by injecting packets with false 354 addresses and/or labels. Theft of service is not further discussed 355 in this document, since it can only be analysed for specific stateful 356 methods of using the flow label. However, a denial of service attack 357 becomes possible in the stateless model when the modified or injected 358 traffic depletes the resources available to forward it and other 359 traffic streams. If a DoS attack were undertaken against a given 360 Flow Label (or set of Flow Labels), then traffic containing an 361 affected Flow Label might well experience worse-than-best-effort 362 network performance. 364 Note that since the treatment of IP headers by nodes is typically 365 unverified, there is no guarantee that flow labels sent by a node are 366 set according to the recommendations in this document. A man-in-the- 367 middle or injected-traffic denial of service attack specifically 368 directed at flow label handling would involve setting unusual flow 369 labels. For example, an attacker could set all flow labels reaching 370 a given router to the same arbitrary non-zero value, or could perform 371 rapid cycling of flow label values such that the packets of a given 372 flow will each have a different value. Either of these attacks would 373 cause a stateless load distribution algorithm to perform badly and 374 would cause a stateful classifier to behave incorrectly. For this 375 reason, stateless classifiers should not use the flow label alone to 376 control load distribution, and stateful classifiers should include 377 explicit methods to detect and ignore suspect flow label values. 379 Since flows are identified by the 3-tuple of the Flow Label and the 380 Source and Destination Address, the risk of denial of service 381 introduced by the Flow Label is closely related to the risk of denial 382 of service by address spoofing. An adversary who is in a position to 383 forge an address is also likely to be able to forge a label, and vice 384 versa. 386 There are two issues with different properties: Spoofing of the Flow 387 Label only, and spoofing of the whole 3-tuple, including Source and 388 Destination Address. 390 The former can be done inside a node which is using or transmitting 391 the correct source address. The ability to spoof a Flow Label 392 typically implies being in a position to also forge an address, but 393 in many cases, spoofing an address may not be interesting to the 394 spoofer, especially if the spoofer's goal is theft of service, rather 395 than denial of service. 397 The latter can be done by a host which is not subject to ingress 398 filtering [RFC2827] or by an intermediate router. Due to its 399 properties, this is typically useful only for denial of service. In 400 the absence of ingress filtering, almost any third party could 401 instigate such an attack. 403 In the presence of ingress filtering, forging a non-zero Flow Label 404 on packets that originated with a zero label, or modifying or 405 clearing a label, could only occur if an intermediate system such as 406 a router was compromised, or through some other form of man-in-the- 407 middle attack. 409 6.3. IPsec and Tunneling Interactions 411 The IPsec protocol, as defined in [RFC4301], [RFC4302], [RFC4303] 412 does not include the IPv6 header's Flow Label in any of its 413 cryptographic calculations (in the case of tunnel mode, it is the 414 outer IPv6 header's Flow Label that is not included). Hence 415 modification of the Flow Label by a network node has no effect on 416 IPsec end-to-end security, because it cannot cause any IPsec 417 integrity check to fail. As a consequence, IPsec does not provide 418 any defense against an adversary's modification of the Flow Label 419 (i.e., a man-in-the-middle attack). 421 IPsec tunnel mode provides security for the encapsulated IP header's 422 Flow Label. A tunnel mode IPsec packet contains two IP headers: an 423 outer header supplied by the tunnel ingress node and an encapsulated 424 inner header supplied by the original source of the packet. When an 425 IPsec tunnel is passing through nodes performing flow classification, 426 the intermediate network nodes operate on the Flow Label in the outer 427 header. At the tunnel egress node, IPsec processing includes 428 removing the outer header and forwarding the packet (if required) 429 using the inner header. The IPsec protocol requires that the inner 430 header's Flow Label not be changed by this decapsulation processing 431 to ensure that modifications to label cannot be used to launch theft- 432 or denial-of-service attacks across an IPsec tunnel endpoint. This 433 document makes no change to that requirement; indeed it forbids 434 changes to the Flow Label. 436 When IPsec tunnel egress decapsulation processing includes a 437 sufficiently strong cryptographic integrity check of the encapsulated 438 packet (where sufficiency is determined by local security policy), 439 the tunnel egress node can safely assume that the Flow Label in the 440 inner header has the same value as it had at the tunnel ingress node. 442 This analysis and its implications apply to any tunneling protocol 443 that performs integrity checks. Of course, any Flow Label set in an 444 encapsulating IPv6 header is subject to the risks described in the 445 previous section. 447 6.4. Security Filtering Interactions 449 The Flow Label does nothing to eliminate the need for packet 450 filtering based on headers past the IP header, if such filtering is 451 deemed necessary for security reasons on nodes such as firewalls or 452 filtering routers. 454 7. Differences from RFC 3697 456 The main differences between this specification and its predecessor 457 are as follows: 458 o This specification encourages non-zero flow label values to be 459 used, and clearly defines how to set a non-zero value. 460 o It encourages a stateless model with uniformly distributed flow 461 label values. 462 o It does not specify any details of a stateful model. 463 o It retains the rule that the flow label must not be changed en 464 route, but allows routers to set the label on behalf of hosts that 465 do not do so. 466 o It discusses the covert channel risk and its consequences for 467 firewalls. 469 For further details see [I-D.ietf-6man-flow-update]. 471 8. IANA Considerations 473 This document requests no action by IANA. 475 9. Acknowledgements 477 Valuable comments and contributions were made by Ran Atkinson, Fred 478 Baker, Steve Blake, Remi Despres, Alan Ford, Fernando Gont, Brian 479 Haberman, Tony Hain, Joel Halpern, Qinwen Hu, Chris Morrow, Thomas 480 Narten, Mark Smith, Pascal Thubert, Iljitsch van Beijnum, and other 481 participants in the 6man working group. 483 Cristian Calude suggested the von Neumann algorithm in Appendix A. 485 Steve Deering and Alex Conta were co-authors of RFC 3697, on which 486 this document is based. 488 Contributors to the original development of RFC 3697 included Ran 489 Atkinson, Steve Blake, Jim Bound, Francis Dupont, Robert Elz, Tony 490 Hain, Robert Hancock, Bob Hinden, Christian Huitema, Frank 491 Kastenholz, Thomas Narten, Charles Perkins, Pekka Savola, Hesham 492 Soliman, Michael Thomas, Margaret Wasserman, and Alex Zinin. 494 This document was produced using the xml2rfc tool [RFC2629]. 496 10. Change log [RFC Editor: Please remove] 498 draft-ietf-6man-flow-3697bis-04: update to resolve further WG 499 comments, 2011-05-11: 500 o Suggested a specific hash algorithm to generate a flow label. 501 o Removed reference to stateful domain. 502 o Added text about covert channel and tuned text about firewall 503 behavior; removed the confusing word "immutable". 504 o Added that Section 6 of RFC 2460 is replaced. 505 o Editorial fixes. 507 draft-ietf-6man-flow-3697bis-03: update to resolve WGLC comments, 508 2011-05-02: 509 o Clarified that the network layer view of flows is agnostic about 510 transport sessions. 511 o Honed the definition of stateless v stateful models. 512 o Honed the text about using a pseudo-random function. 513 o Moved material about violation of immutability to Security 514 section, and rephrased accordingly. 516 o Dropped material about setting the flow label at a domain exit 517 router: doesn't belong here now that we have dropped almost all 518 the stateful text. 519 o Removed normative reference to draft-gont-6man-flowlabel-security. 520 o Removed the statement that a node that does not set or use the 521 flow label must ignore it: this statement appears to be a no-op. 522 o Added a summary of changes from RFC 3697. 523 o Miscellaneous editorial fixes. 525 draft-ietf-6man-flow-3697bis-02: update to remove most text about 526 stateful methods, 2011-03-13 528 draft-ietf-6man-flow-3697bis-01: update after resolving 11 initial 529 issues, 2011-02-26 531 draft-ietf-6man-flow-3697bis-00: original version, built from RFC3697 532 and draft-ietf-6man-flow-update-01, 2011-01-31 534 11. References 536 11.1. Normative References 538 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 539 Requirement Levels", BCP 14, RFC 2119, March 1997. 541 [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. 542 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 543 Functional Specification", RFC 2205, September 1997. 545 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 546 (IPv6) Specification", RFC 2460, December 1998. 548 11.2. Informative References 550 [I-D.gont-6man-flowlabel-security] 551 Gont, F., "Security Assessment of the IPv6 Flow Label", 552 draft-gont-6man-flowlabel-security-01 (work in progress), 553 November 2010. 555 [I-D.ietf-6man-flow-update] 556 Amante, S., Carpenter, B., and S. Jiang, "Rationale for 557 update to the IPv6 flow label specification", 558 draft-ietf-6man-flow-update-05 (work in progress), 559 May 2011. 561 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 562 June 1999. 564 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 565 Defeating Denial of Service Attacks which employ IP Source 566 Address Spoofing", BCP 38, RFC 2827, May 2000. 568 [RFC3697] Rajahalme, J., Conta, A., Carpenter, B., and S. Deering, 569 "IPv6 Flow Label Specification", RFC 3697, March 2004. 571 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 572 Internet Protocol", RFC 4301, December 2005. 574 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, 575 December 2005. 577 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 578 RFC 4303, December 2005. 580 [vonNeumann] 581 von Neumann, J., "Various techniques used in connection 582 with random digits", National Bureau of Standards Applied 583 Math Series 12, 36-38, 1951. 585 Appendix A. Simple 20-bit Hash Function 587 As mentioned in Section 3, a stateless hash function may be used to 588 generate a flow label value from an IPv6 packet's 5-tuple. An 589 example function, based on an algorithm by von Neumann known to 590 produce an approximately uniform distribution [vonNeumann], is as 591 follows: 593 1. Split the destination and source addresses into two 64 bit values 594 each, thus transforming the 5-tuple into a 7-tuple. 595 2. Add the seven components together using unsigned 64 bit 596 arithmetic, discarding any carry bits. 597 3. Apply the von Neumann algorithm to the resulting string of 64 598 bits: 599 1. Starting at the least significant end, select two bits. 600 2. If the two bits are 00 or 11, discard them. 601 3. If the two bits are 01, output a 0 bit. 602 4. If the two bits are 10, output a 1 bit. 603 5. Repeat with the next two bits in the input 64 bit string. 604 6. Stop when 20 bits have been output (or when the 64 bit string 605 is exhausted). 606 4. In the highly unlikely event that the result is exactly zero, set 607 the flow label arbitrarily to the value 1. 609 Authors' Addresses 611 Shane Amante 612 Level 3 Communications, LLC 613 1025 Eldorado Blvd 614 Broomfield, CO 80021 615 USA 617 Email: shane@level3.net 619 Brian Carpenter 620 Department of Computer Science 621 University of Auckland 622 PB 92019 623 Auckland, 1142 624 New Zealand 626 Email: brian.e.carpenter@gmail.com 628 Sheng Jiang 629 Huawei Technologies Co., Ltd 630 Huawei Building, No.3 Xinxi Rd., 631 Shang-Di Information Industry Base, Hai-Dian District, Beijing 632 P.R. China 634 Email: jiangsheng@huawei.com 636 Jarno Rajahalme 637 Nokia Siemens Networks 638 Linnoitustie 6 639 02600 Espoo 640 Finland 642 Email: jarno.rajahalme@nsn.com