idnits 2.17.1 draft-ietf-6man-flow-3697bis-01.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 (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 (February 26, 2011) is 4801 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) == Outdated reference: A later version (-03) exists of draft-gont-6man-flowlabel-security-01 ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) == Outdated reference: A later version (-07) exists of draft-ietf-6man-flow-update-02 -- 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 (~~), 3 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: August 30, 2011 Huawei Technologies Co., Ltd 8 J. Rajahalme 9 Nokia-Siemens Networks 10 February 26, 2011 12 IPv6 Flow Label Specification 13 draft-ietf-6man-flow-3697bis-01 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 August 30, 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. Stateless Flow Labeling Requirements . . . . . . . . . . . . . 7 77 4. Flow State Establishment Requirements . . . . . . . . . . . . 8 78 5. Essential correction to RFC 2205 . . . . . . . . . . . . . . . 9 79 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 80 6.1. Theft and Denial of Service . . . . . . . . . . . . . . . 9 81 6.2. IPsec and Tunneling Interactions . . . . . . . . . . . . . 11 82 6.3. Security Filtering Interactions . . . . . . . . . . . . . 12 83 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 84 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 85 9. Change log . . . . . . . . . . . . . . . . . . . . . . . . . . 13 86 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 87 10.1. Normative References . . . . . . . . . . . . . . . . . . . 13 88 10.2. Informative References . . . . . . . . . . . . . . . . . . 13 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 91 1. Introduction 93 A flow is a sequence of packets sent from a particular source to a 94 particular unicast, anycast, or multicast destination that a node 95 desires to label as a flow. A flow could consist of all packets in a 96 specific transport connection or a media stream. However, a flow is 97 not necessarily 1:1 mapped to a transport connection. 99 Traditionally, flow classifiers have been based on the 5-tuple of the 100 source and destination addresses, ports, and the transport protocol 101 type. However, some of these fields may be unavailable due to either 102 fragmentation or encryption, or locating them past a chain of IPv6 103 extension headers may be inefficient. Additionally, if classifiers 104 depend only on IP layer headers, later introduction of alternative 105 transport layer protocols will be easier. 107 The usage of the 3-tuple of the Flow Label and the Source and 108 Destination Address fields enables efficient IPv6 flow 109 classification, where only IPv6 main header fields in fixed positions 110 are used. 112 The flow label could be used in both stateless and stateful 113 scenarios. A stateless scenario is one where a node that sets the 114 flow label value for all packets of a given flow does not need to 115 store any information about the flow, and any node that processes the 116 flow label in any way also does not need to store any information 117 after a packet has been processed. A stateful scenario is one where 118 a node that sets or processes the flow label value needs to store 119 information about the flow, including the flow label value. A 120 stateful scenario might also require a signaling mechanism to 121 establish flow state in the network. 123 The flow label can be used most simply in stateless scenarios. This 124 specification concentrates on the stateless model and how it can be 125 used as a default mechanism. Details of stateful models, signaling, 126 specific flow state establishment methods and their related service 127 models are out of scope for this specification. Generic requirements 128 enabling co-existence of different models are set forth in Section 4. 129 The associated scaling characteristics (such as nodes involved in 130 state establishment, amount of state maintained by them, and state 131 growth function) will be specific to particular service models. 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 Appendix A of [RFC2460]. A 147 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 not part of any flow. Packet classifiers can use 160 the triplet of Flow Label, Source Address, and Destination Address 161 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. However, any node that sets flow label values 167 according to a stateful scheme MUST ensure that packets conform to 168 Section 3 of the present specification if they are sent outside the 169 network domain using the stateful scheme. 171 As specified below in Section 3, the normal expectation is that flow 172 label values are uniformly distributed. In this specification, it is 173 recommended below that a pseudo-random method should be used to 174 achieve such a uniform distribution. Intentionally, there are no 175 precise mathematical requirements placed on the distribution or the 176 pseudo-random method. 178 Once set to a non-zero value, the Flow Label MUST be delivered 179 unchanged to the destination node(s). A forwarding node MUST NOT 180 change the flow label value in an arriving packet if it is non-zero. 181 However, there are two qualifications to this rule: 182 1. Implementers are advised that forwarding nodes, especially those 183 acting as domain border devices, might nevertheless be configured 184 to change the flow label value in packets. This is undetectable, 185 unless some future version of IPsec authentication [RFC4302] 186 protects the flow label value. 187 2. To enable stateless load distribution at any point in the 188 Internet, a network domain should never export packets 189 originating within the domain whose flow label values do not 190 conform to Section 3. However, neither domain border egress 191 routers nor intermediate routers/devices (using a flow-label, for 192 example, as a part of an input-key for a load-distribution hash) 193 can determine by inspection that a value is not part of a uniform 194 distribution. Therefore, if nodes within a domain ignore the 195 recommendations of Section 3, and such packets are forwarded 196 outside the domain, this might result in undesirable operational 197 implications (e.g., congestion, reordering) for not only the 198 inappropriately flow-labelled packets, but also well-behaved 199 flow-labelled packets, during forwarding at various intermediate 200 devices. Thus, a domain must protect its peers by never 201 exporting inappropriately labelled packets originating within the 202 domain. This is why nodes using a stateful scheme must not set 203 the flow label to a non-zero and non-uniformly distributed value 204 if the packet will leave their domain. If it is known to a 205 border router that flow labels originated within the domain are 206 not uniformly distributed, it will need to set outgoing flow 207 labels in the same manner as described for forwarding nodes in 208 Section 3. 210 There is no way to verify whether a flow label has been modified en 211 route or whether it belongs to a uniform distribution. Therefore, no 212 Internet-wide mechanism can depend mathematically on immutable and 213 uniformly distributed flow labels; they have a "best effort" quality. 214 This leads to the following formal rules: 215 o Implementers should be aware that the flow label is an unprotected 216 field that could have been accidentally or intentionally changed 217 en route. Implementations MUST take appropriate steps to protect 218 themselves from being vulnerable to denial of service and other 219 types of attack that could result (see Section 6.1). 220 o Forwarding nodes such as routers and load balancers MUST NOT 221 depend only on Flow Label values being uniformly distributed. In 222 any usage such as a hash key for load distribution, the Flow Label 223 bits MUST be combined at least with bits from other sources within 224 the packet, so as to produce a constant hash value for each flow 225 and a suitable distribution of hash values across flows. 227 Although uniformly distributed flow label values are recommended 228 below, and will always be helpful for load balancing, it is unsafe to 229 assume their presence in the general case, and the use case needs to 230 work even if the flow label value is zero. 232 The use of the Flow Label field does not necessarily signal any 233 requirement on packet reordering. Especially, the zero label does 234 not imply that significant reordering is acceptable. 236 An IPv6 node that does not set the flow label to a non-zero value, or 237 make use of it in any way, MUST ignore it when receiving or 238 forwarding a packet. 240 3. Stateless Flow Labeling Requirements 242 This section defines the minimum requirements for stateless methods 243 of setting the flow label value. 245 To enable Flow Label based classification, source nodes SHOULD assign 246 each unrelated transport connection and application data stream to a 247 new flow. A typical definition of a flow for this purpose is any set 248 of packets carrying the same 5-tuple {dest addr, source addr, 249 protocol, dest port, source port}. 251 It is desirable that flow label values should be uniformly 252 distributed to assist load distribution. It is therefore RECOMMENDED 253 that source hosts support the flow label by setting the flow label 254 field for all packets of a given flow to the same uniformly 255 distributed pseudo-random value. Both stateful and stateless methods 256 of assigning a pseudo-random value could be used, but it is outside 257 the scope of this specification to mandate an algorithm. In a 258 stateless mechanism, the algorithm SHOULD ensure that the resulting 259 flow label values are unique with high probability. 261 An OPTIONAL algorithm for generating such a pseudo-random value is 262 described in [I-D.gont-6man-flowlabel-security]. 264 [[ NOTE TO RFC EDITOR: The preceding sentence should be deleted, and 265 the reference should be changed to Informative, if the cited draft is 266 not on the standards track at the time of publication. ]] 268 A source node which does not otherwise set the flow label MUST set 269 its value to zero. 271 A node that forwards a flow whose flow label value in arriving 272 packets is zero MAY set the flow label value. In that case, it is 273 RECOMMENDED that the forwarding node sets the flow label field for a 274 flow to a uniformly distributed pseudo-random value. 275 o The same considerations apply as to source hosts setting the flow 276 label; in particular, the normal case is that a flow is defined by 277 the 5-tuple. 278 o This option, if implemented, would presumably be used by first-hop 279 or ingress routers. It might place a considerable per-packet 280 processing load on them, even if they adopted a stateless method 281 of flow identification and label assignment. This is why the 282 principal recommendation is that the source host should set the 283 label. 285 The preceding rules taken together allow a given network domain to 286 include routers that set flow labels on behalf of hosts that do not 287 do so. They also recommend that flow labels exported to the Internet 288 are always either zero or uniformly distributed. 290 4. Flow State Establishment Requirements 292 This section defines the minimum requirements for stateful methods of 293 setting the flow label value. 295 The node that sets the flow label MAY also take part in flow state 296 establishment methods that result in assigning specific treatments to 297 specific flows, possibly including signaling. 298 o In this case, unlike the stateless case, a source node MUST ensure 299 that it does not unintentionally reuse Flow Label values it is 300 currently using or has recently used when creating new flows. 301 Flow Label values previously used with a specific pair of source 302 and destination addresses MUST NOT be assigned to new flows with 303 the same address pair within 120 seconds of the termination of the 304 previous flow. 305 o To avoid accidental Flow Label value reuse, the source node SHOULD 306 select new Flow Label values in a well-defined way and use an 307 initial value that avoids reuse of recently used Flow Label values 308 each time the system restarts. The initial value SHOULD be 309 derived from a previous value stored in non-volatile memory, or in 310 the absence of such history, a randomly generated initial value 311 using techniques that produce good randomness properties SHOULD be 312 used. 314 To enable stateful flow-specific treatment, flow state needs to be 315 established on all or a subset of the IPv6 nodes on the path from the 316 source to the destination(s). The methods for the state 317 establishment, as well as the models for flow-specific treatment will 318 be defined in separate specifications. 320 In stateful mechanisms, nodes keeping dynamic flow state MUST NOT 321 assume packets arriving 120 seconds or more after the previous packet 322 of a flow still belong to the same flow, unless a flow state 323 establishment method in use defines a longer flow state lifetime or 324 the flow state has been explicitly refreshed within the lifetime 325 duration. 327 To enable co-existence of different methods in IPv6 nodes, the 328 methods MUST meet the following basic requirements: 329 o The method MUST provide the means for flow state clean-up from the 330 IPv6 nodes providing the flow-specific treatment. Signaling based 331 methods where the source node is involved are free to specify flow 332 state lifetimes longer than the default 120 seconds. 333 o Flow state establishment methods MUST be able to recover from the 334 case where the requested flow state cannot be supported. 336 5. Essential correction to RFC 2205 338 [RFC2460] reduced the size of the flow label field from 24 to 20 339 bits. The references to a 24 bit flow label field on pages 87 and 88 340 of [RFC2205] are updated accordingly. 342 6. Security Considerations 344 This section considers security issues raised by the use of the Flow 345 Label, primarily the potential for denial-of-service attacks, and the 346 related potential for theft of service by unauthorized traffic 347 (Section 6.1). Section 6.2 addresses the use of the Flow Label in 348 the presence of IPsec including its interaction with IPsec tunnel 349 mode and other tunneling protocols. We also note that inspection of 350 unencrypted Flow Labels may allow some forms of traffic analysis by 351 revealing some structure of the underlying communications. Even if 352 the flow label were encrypted, its presence as a constant value in a 353 fixed position might assist traffic analysis and cryptoanalysis. 355 The flow label is not protected in any way and can be forged by an 356 on-path attacker. On the other hand, a uniformly distributed pseudo- 357 random flow label cannot be readily guessed by an off-path attacker; 358 see [I-D.gont-6man-flowlabel-security] for further discussion. 360 6.1. Theft and Denial of Service 362 Since the mapping of network traffic to flow-specific treatment is 363 triggered by the IP addresses and Flow Label value of the IPv6 364 header, an adversary may be able to obtain better service by 365 modifying the IPv6 header or by injecting packets with false 366 addresses and/or labels. Taken to its limits, such theft-of-service 367 becomes a denial-of-service attack when the modified or injected 368 traffic depletes the resources available to forward it and other 369 traffic streams. A curiosity is that if a DoS attack were undertaken 370 against a given Flow Label (or set of Flow Labels), then traffic 371 containing an affected Flow Label might well experience worse-than- 372 best-effort network performance. 374 Note that since the treatment of IP headers by nodes is typically 375 unverified, there is no guarantee that flow labels sent by a node are 376 set according to the recommendations in this document. Therefore, 377 any assumptions made by the network about header fields such as flow 378 labels should be limited to the extent that the upstream nodes are 379 explicitly trusted. 381 Since flows are identified by the 3-tuple of the Flow Label and the 382 Source and Destination Address, the risk of theft or denial of 383 service introduced by the Flow Label is closely related to the risk 384 of theft or denial of service by address spoofing. An adversary who 385 is in a position to forge an address is also likely to be able to 386 forge a label, and vice versa. 388 There are two issues with different properties: Spoofing of the Flow 389 Label only, and spoofing of the whole 3-tuple, including Source and 390 Destination Address. 392 The former can be done inside a node which is using or transmitting 393 the correct source address. The ability to spoof a Flow Label 394 typically implies being in a position to also forge an address, but 395 in many cases, spoofing an address may not be interesting to the 396 spoofer, especially if the spoofer's goal is theft of service, rather 397 than denial of service. 399 The latter can be done by a host which is not subject to ingress 400 filtering [RFC2827] or by an intermediate router. Due to its 401 properties, such is typically useful only for denial of service. In 402 the absence of ingress filtering, almost any third party could 403 instigate such an attack. 405 In the presence of ingress filtering, forging a non-zero Flow Label 406 on packets that originated with a zero label, or modifying or 407 clearing a label, could only occur if an intermediate system such as 408 a router was compromised, or through some other form of man-in-the- 409 middle attack. However, the risk is limited to traffic receiving 410 better or worse quality of service than intended. For example, if 411 Flow Labels are altered or cleared at random, flow classification 412 will no longer happen as intended, and the altered packets will 413 receive default treatment. If a complete 3-tuple is forged, the 414 altered packets will be classified into the forged flow and will 415 receive the corresponding quality of service; this will create a 416 denial of service attack subtly different from one where only the 417 addresses are forged. Because it is limited to a single flow 418 definition, e.g., to a limited amount of bandwidth, such an attack 419 will be more specific and at a finer granularity than a normal 420 address-spoofing attack. 422 Since flows are identified by the complete 3-tuple, ingress filtering 423 [RFC2827] will, as noted above, mitigate part of the risk. If the 424 source address of a packet is validated by ingress filtering, there 425 can be a degree of trust that the packet has not transited a 426 compromised router, to the extent that ISP infrastructure may be 427 trusted. However, this gives no assurance that another form of man- 428 in-the-middle attack has not occurred. 430 A man-in-the-middle denial of service attack specifically directed at 431 flow label handling would involve setting unusual flow labels. For 432 example, an attacker could set all flow labels reaching a given 433 router to the same arbitrary non-zero value, or could perform rapid 434 cycling of flow label values such that the packets of a given flow 435 will each have a different value. Either of these attacks would 436 cause a stateless load distribution algorithm to perform badly and 437 would cause a stateful mechanism to behave incorrectly. For this 438 reason, stateless mechanisms should not use the flow label alone to 439 control load distribution, and stateful mechanisms should include 440 explicit methods to detect and ignore suspect flow label values. 442 6.2. IPsec and Tunneling Interactions 444 The IPsec protocol, as defined in [RFC4301], [RFC4302], [RFC4303] 445 does not include the IPv6 header's Flow Label in any of its 446 cryptographic calculations (in the case of tunnel mode, it is the 447 outer IPv6 header's Flow Label that is not included). Hence 448 modification of the Flow Label by a network node has no effect on 449 IPsec end-to-end security, because it cannot cause any IPsec 450 integrity check to fail. As a consequence, IPsec does not provide 451 any defense against an adversary's modification of the Flow Label 452 (i.e., a man-in-the-middle attack). 454 IPsec tunnel mode provides security for the encapsulated IP header's 455 Flow Label. A tunnel mode IPsec packet contains two IP headers: an 456 outer header supplied by the tunnel ingress node and an encapsulated 457 inner header supplied by the original source of the packet. When an 458 IPsec tunnel is passing through nodes performing flow classification, 459 the intermediate network nodes operate on the Flow Label in the outer 460 header. At the tunnel egress node, IPsec processing includes 461 removing the outer header and forwarding the packet (if required) 462 using the inner header. The IPsec protocol requires that the inner 463 header's Flow Label not be changed by this decapsulation processing 464 to ensure that modifications to label cannot be used to launch theft- 465 or denial-of-service attacks across an IPsec tunnel endpoint. This 466 document makes no change to that requirement; indeed it forbids 467 changes to the Flow Label. 469 When IPsec tunnel egress decapsulation processing includes a 470 sufficiently strong cryptographic integrity check of the encapsulated 471 packet (where sufficiency is determined by local security policy), 472 the tunnel egress node can safely assume that the Flow Label in the 473 inner header has the same value as it had at the tunnel ingress node. 475 This analysis and its implications apply to any tunneling protocol 476 that performs integrity checks. Of course, any Flow Label set in an 477 encapsulating IPv6 header is subject to the risks described in the 478 previous section. 480 6.3. Security Filtering Interactions 482 The Flow Label does nothing to eliminate the need for packet 483 filtering based on headers past the IP header, if such filtering is 484 deemed necessary for security reasons on nodes such as firewalls or 485 filtering routers. 487 However, security devices that clear or rewrite non-zero flow label 488 values would be in violation of this specification. 490 7. IANA Considerations 492 This document requests no action by IANA. 494 8. Acknowledgements 496 Steve Deering and Alex Conta were co-authors of RFC 3697, on which 497 this document is based. 499 Valuable comments and contributions were made by Fred Baker, Steve 500 Blake, Remi Despres, Alan Ford, Fernando Gont, Brian Haberman, Tony 501 Hain, Joel Halpern, Qinwen Hu, Chris Morrow, Thomas Narten, Mark 502 Smith, Pascal Thubert, Iljitsch van Beijnum, and other participants 503 in the 6man working group. 505 Contributors to the development of RFC 3697 included Ran Atkinson, 506 Steve Blake, Jim Bound, Francis Dupont, Robert Elz, Tony Hain, Robert 507 Hancock, Bob Hinden, Christian Huitema, Frank Kastenholz, Thomas 508 Narten, Charles Perkins, Pekka Savola, Hesham Soliman, Michael 509 Thomas, Margaret Wasserman, and Alex Zinin. 511 This document was produced using the xml2rfc tool [RFC2629]. 513 9. Change log 515 draft-ietf-6man-flow-3697bis-01: update after resolving 11 initial 516 issues, 2011-02-26 518 draft-ietf-6man-flow-3697bis-00: original version, built from RFC3697 519 and draft-ietf-6man-flow-update-01, 2011-01-31 521 10. References 523 10.1. Normative References 525 [I-D.gont-6man-flowlabel-security] 526 Gont, F., "Security Assessment of the IPv6 Flow Label", 527 draft-gont-6man-flowlabel-security-01 (work in progress), 528 November 2010. 530 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 531 Requirement Levels", BCP 14, RFC 2119, March 1997. 533 [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. 534 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 535 Functional Specification", RFC 2205, September 1997. 537 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 538 (IPv6) Specification", RFC 2460, December 1998. 540 10.2. Informative References 542 [I-D.ietf-6man-flow-update] 543 Amante, S., Carpenter, B., and S. Jiang, "Rationale for 544 update to the IPv6 flow label specification", 545 draft-ietf-6man-flow-update-02 (work in progress), 546 January 2011. 548 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 549 June 1999. 551 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 552 Defeating Denial of Service Attacks which employ IP Source 553 Address Spoofing", BCP 38, RFC 2827, May 2000. 555 [RFC3697] Rajahalme, J., Conta, A., Carpenter, B., and S. Deering, 556 "IPv6 Flow Label Specification", RFC 3697, March 2004. 558 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 559 Internet Protocol", RFC 4301, December 2005. 561 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, 562 December 2005. 564 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 565 RFC 4303, December 2005. 567 Authors' Addresses 569 Shane Amante 570 Level 3 Communications, LLC 571 1025 Eldorado Blvd 572 Broomfield, CO 80021 573 USA 575 Email: shane@level3.net 577 Brian Carpenter 578 Department of Computer Science 579 University of Auckland 580 PB 92019 581 Auckland, 1142 582 New Zealand 584 Email: brian.e.carpenter@gmail.com 586 Sheng Jiang 587 Huawei Technologies Co., Ltd 588 Huawei Building, No.3 Xinxi Rd., 589 Shang-Di Information Industry Base, Hai-Dian District, Beijing 590 P.R. China 592 Email: shengjiang@huawei.com 594 Jarno Rajahalme 595 Nokia-Siemens Networks 596 TBD 597 TBD 598 Finland 600 Email: jarno.rajahalme@nsn.com