idnits 2.17.1 draft-ietf-6man-flow-3697bis-00.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 (January 31, 2011) is 4833 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-01 -- 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 Univ. of Auckland 6 (if approved) S. Jiang 7 Intended status: Standards Track Huawei Technologies Co., Ltd 8 Expires: August 4, 2011 J. Rajahalme 9 Nokia-Siemens Networks 10 January 31, 2011 12 IPv6 Flow Label Specification 13 draft-ietf-6man-flow-3697bis-00 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 1, 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 . . . . . . . . . . . . . . . . . . 6 77 4. Flow State Establishment Requirements . . . . . . . . . . . . 8 78 5. Essential correction to RFC 2205 . . . . . . . . . . . . . . . 8 79 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 80 6.1. Theft and Denial of Service . . . . . . . . . . . . . . . 9 81 6.2. IPsec and Tunneling Interactions . . . . . . . . . . . . . 10 82 6.3. Security Filtering Interactions . . . . . . . . . . . . . 11 83 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 84 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 85 9. Change log . . . . . . . . . . . . . . . . . . . . . . . . . . 12 86 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 87 10.1. Normative References . . . . . . . . . . . . . . . . . . . 12 88 10.2. Informative References . . . . . . . . . . . . . . . . . . 12 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 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 minimum level of IPv6 flow support consists of labeling the 113 flows. A specific goal is to enable and encourage the use of the 114 flow label for various forms of stateless load distribution, 115 especially across Equal Cost Multi-Path (EMCP) and/or Link 116 Aggregation Group (LAG) paths. ECMP and LAG are methods to bond 117 together multiple physical links used to procure the required 118 capacity necessary to carry an offered load greater than the 119 bandwidth of an individual physical link. IPv6 source nodes SHOULD 120 be able to label known flows (e.g., TCP connections, application 121 streams), even if the node itself does not require any flow-specific 122 treatment. Node requirements for flow labeling are given in 123 Section 3. 125 The flow label can be used most simply in stateless models, but 126 stateful mechanisms are also possible. Specific flow state 127 establishment methods and the related service models are out of scope 128 for this specification, but the generic requirements enabling co- 129 existence of different methods in IPv6 nodes are set forth in 130 Section 4. The associated scaling characteristics (such as nodes 131 involved in state establishment, amount of state maintained by them, 132 and state growth function) will be specific to particular service 133 models. 135 This document replaces [RFC3697] and Appendix A of [RFC2460]. A 136 rationale for the changes made is documented in 137 [I-D.ietf-6man-flow-update]. The present document also includes a 138 correction to [RFC2205] concerning the flow label. 140 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 141 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 142 document are to be interpreted as described in [RFC2119]. 144 2. IPv6 Flow Label Specification 146 The 20-bit Flow Label field in the IPv6 header [RFC2460] is used by a 147 node to label packets of a flow. A Flow Label of zero is used to 148 indicate packets not part of any flow. Packet classifiers can use 149 the triplet of Flow Label, Source Address, and Destination Address 150 fields to identify which flow a particular packet belongs to. 151 Packets are processed in a flow-specific manner by nodes that are 152 able to do so in a stateless manner, or that have been set up with 153 flow-specific state. The nature of the specific treatment and the 154 methods for flow state establishment are out of scope for this 155 specification. 157 Once set to a non-zero value, the Flow Label MUST be delivered 158 unchanged to the destination node(s). A forwarding node MUST NOT 159 change the flow label value in an arriving packet if it is non-zero. 160 However, there are two qualifications to this rule: 161 1. Implementers are advised that forwarding nodes, especially those 162 acting as domain border devices, might nevertheless be configured 163 to change the flow label value in packets (e.g., to a new pseudo- 164 random value). This is undetectable, unless some future version 165 of IPsec authentication [RFC4302] protects the flow label value. 166 2. To enable stateless load distribution at any point in the 167 Internet, a network domain MUST NOT forward packets outside the 168 domain whose flow label values are other than zero or pseudo- 169 random. Neither domain border egress routers nor intermediate 170 routers/devices (using a flow-label, for example, as a part of an 171 input-key for a load-distribution hash) can determine by 172 inspection that a value is not pseudo-random. Therefore, if 173 nodes within a domain ignore the above recommendations to set 174 zero or pseudo-random flow label values, and such packets are 175 forwarded outside the domain, this would likely result in 176 undesirable operational implications (e.g., congestion, 177 reordering) for not only the inappropriately flow-labelled 178 packets, but also well-behaved flow-labelled packets, during 179 forwarding at various intermediate devices. Thus, a domain must 180 protect its peers by never exporting inappropriately labelled 181 packets. This document does not specify the method for enforcing 182 this rule. The suggested way to enforce it is that nodes within 183 a domain MUST NOT set the flow label to a non-zero and non- 184 pseudo-random number if the packet will leave the domain. If 185 this is not known to be the case, the border router will need to 186 change outgoing flow labels. 188 There is no way to verify whether a flow label has been modified en 189 route. Therefore, no Internet-wide mechanism can depend 190 mathematically on immutable flow labels; they have a "best effort" 191 quality. This leads to the following formal rules: 193 IPv6 nodes MUST NOT assume that the Flow Label value in a incoming 194 packet is identical to the value set by the source node. 196 Forwarding nodes such as routers and load balancers MUST NOT depend 197 only on Flow Label values being randomly distributed. In any usage 198 such as a hash key for load distribution, the Flow Label bits MUST be 199 combined with bits from other sources within the packet, so as to 200 produce a constant hash value for each flow and a suitable 201 distribution of hash values across flows. 203 Although a pseudo-random flow label is recommended, and will always 204 be helpful for load balancing, it is unsafe to assume its presence in 205 the general case, and the use case needs to work even if the flow 206 label value is zero. 208 Nodes keeping dynamic flow state MUST NOT assume packets arriving 120 209 seconds or more after the previous packet of a flow still belong to 210 the same flow, unless a flow state establishment method in use 211 defines a longer flow state lifetime or the flow state has been 212 explicitly refreshed within the lifetime duration. 214 The use of the Flow Label field does not necessarily signal any 215 requirement on packet reordering. Especially, the zero label does 216 not imply that significant reordering is acceptable. 218 An IPv6 node that does not set or make use of the flow label MUST 219 ignore it when receiving or forwarding a packet. 221 3. Flow Labeling Requirements 223 To enable Flow Label based classification, source nodes SHOULD assign 224 each unrelated transport connection and application data stream to a 225 new flow. It is RECOMMENDED that source hosts support the flow label 226 by setting the flow label field for all packets of a flow to the same 227 pseudo-random value. Both stateful and stateless methods of 228 assigning a pseudo-random value could be used, but it is outside the 229 scope of this specification to mandate an algorithm. 231 An OPTIONAL algorithm for generating such a pseudo-random value is 232 described in [I-D.gont-6man-flowlabel-security]. 234 [[ QUESTION TO WG: Should we incorporate that algorithm here, or 235 leave it as a separate draft? ]] 237 A source node which does not otherwise set the flow label MUST set 238 its value to zero. 240 A node that forwards a flow whose flow label value in arriving 241 packets is zero MAY set the flow label value. In that case, it is 242 RECOMMENDED that the forwarding node sets the flow label field for a 243 flow to a pseudo-random value. 244 o The same considerations apply as to source hosts setting the flow 245 label. 246 o This option, if implemented, would presumably be used by ingress 247 routers. It would place a considerable per-packet processing load 248 on them, even if they adopted a stateless method of flow 249 identification and label assignment. This is why the principal 250 recommendation is that the source host should set the label. 252 The preceding rules taken together allow a given network domain to 253 include routers that set flow labels on behalf of hosts that do not 254 do so. They also recommend that flow labels exported to the Internet 255 are always either zero or pseudo-random. 257 The node that sets the flow label MAY also take part in flow state 258 establishment methods that result in assigning certain packets to 259 specific flows. 261 To enable applications and transport protocols to define what packets 262 constitute a flow, the source node MUST provide means for the 263 applications and transport protocols to specify the Flow Label values 264 to be used with their flows. The use of the means to specify Flow 265 Label values is subject to appropriate privileges (see Section 6.1). 266 The source node SHOULD be able to select unused Flow Label values for 267 flows not requesting a specific value to be used. 269 [[ QUESTION TO WG: Should we reduce this whole paragraph to a MAY? ]] 271 A source node MUST ensure that it does not unintentionally reuse Flow 272 Label values it is currently using or has recently used when creating 273 new flows. Flow Label values previously used with a specific pair of 274 source and destination addresses MUST NOT be assigned to new flows 275 with the same address pair within 120 seconds of the termination of 276 the previous flow. The source node SHOULD provide the means for the 277 applications and transport protocols to specify quarantine periods 278 longer than the default 120 seconds for individual flows. 280 To avoid accidental Flow Label value reuse, the source node SHOULD 281 select new Flow Label values in a well-defined way and use an initial 282 value that avoids reuse of recently used Flow Label values each time 283 the system restarts. The initial value SHOULD be derived from a 284 previous value stored in non-volatile memory, or in the absence of 285 such history, a randomly generated initial value using techniques 286 that produce good randomness properties SHOULD be used 287 [I-D.gont-6man-flowlabel-security]. 289 4. Flow State Establishment Requirements 291 To enable stateful flow-specific treatment, flow state needs to be 292 established on all or a subset of the IPv6 nodes on the path from the 293 source to the destination(s). The methods for the state 294 establishment, as well as the models for flow-specific treatment will 295 be defined in separate specifications. 297 To enable co-existence of different methods in IPv6 nodes, the 298 methods MUST meet the following basic requirements: 299 1. The method MUST provide the means for flow state clean-up from 300 the IPv6 nodes providing the flow-specific treatment. Signaling 301 based methods where the source node is involved are free to 302 specify flow state lifetimes longer than the default 120 seconds. 303 2. Flow state establishment methods MUST be able to recover from the 304 case where the requested flow state cannot be supported. 306 5. Essential correction to RFC 2205 308 [RFC2460] reduced the size of the flow label field from 24 to 20 309 bits. The references to a 24 bit flow label field on pages 87 and 88 310 of [RFC2205] are updated accordingly. 312 6. Security Considerations 314 This section considers security issues raised by the use of the Flow 315 Label, primarily the potential for denial-of-service attacks, and the 316 related potential for theft of service by unauthorized traffic 317 (Section 6.1). Section 6.2 addresses the use of the Flow Label in 318 the presence of IPsec including its interaction with IPsec tunnel 319 mode and other tunneling protocols. We also note that inspection of 320 unencrypted Flow Labels may allow some forms of traffic analysis by 321 revealing some structure of the underlying communications. Even if 322 the flow label were encrypted, its presence as a constant value in a 323 fixed position might assist traffic analysis and cryptoanalysis. 325 The flow label is not protected in any way and can be forged by an 326 on-path attacker. On the other hand, a pseudo-random flow label 327 cannot be readily guessed by an off-path attacker; see 329 [I-D.gont-6man-flowlabel-security] for further discussion. 331 6.1. Theft and Denial of Service 333 Since the mapping of network traffic to flow-specific treatment is 334 triggered by the IP addresses and Flow Label value of the IPv6 335 header, an adversary may be able to obtain better service by 336 modifying the IPv6 header or by injecting packets with false 337 addresses and/or labels. Taken to its limits, such theft-of-service 338 becomes a denial-of-service attack when the modified or injected 339 traffic depletes the resources available to forward it and other 340 traffic streams. A curiosity is that if a DoS attack were undertaken 341 against a given Flow Label (or set of Flow Labels), then traffic 342 containing an affected Flow Label might well experience worse-than- 343 best-effort network performance. 345 Note that since the treatment of IP headers by nodes is typically 346 unverified, there is no guarantee that flow labels sent by a node are 347 set according to the recommendations in this document. Therefore, 348 any assumptions made by the network about header fields such as flow 349 labels should be limited to the extent that the upstream nodes are 350 explicitly trusted. 352 Since flows are identified by the 3-tuple of the Flow Label and the 353 Source and Destination Address, the risk of theft or denial of 354 service introduced by the Flow Label is closely related to the risk 355 of theft or denial of service by address spoofing. An adversary who 356 is in a position to forge an address is also likely to be able to 357 forge a label, and vice versa. 359 There are two issues with different properties: Spoofing of the Flow 360 Label only, and spoofing of the whole 3-tuple, including Source and 361 Destination Address. 363 The former can be done inside a node which is using or transmitting 364 the correct source address. The ability to spoof a Flow Label 365 typically implies being in a position to also forge an address, but 366 in many cases, spoofing an address may not be interesting to the 367 spoofer, especially if the spoofer's goal is theft of service, rather 368 than denial of service. 370 The latter can be done by a host which is not subject to ingress 371 filtering [RFC2827] or by an intermediate router. Due to its 372 properties, such is typically useful only for denial of service. In 373 the absence of ingress filtering, almost any third party could 374 instigate such an attack. 376 In the presence of ingress filtering, forging a non-zero Flow Label 377 on packets that originated with a zero label, or modifying or 378 clearing a label, could only occur if an intermediate system such as 379 a router was compromised, or through some other form of man-in-the- 380 middle attack. However, the risk is limited to traffic receiving 381 better or worse quality of service than intended. For example, if 382 Flow Labels are altered or cleared at random, flow classification 383 will no longer happen as intended, and the altered packets will 384 receive default treatment. If a complete 3-tuple is forged, the 385 altered packets will be classified into the forged flow and will 386 receive the corresponding quality of service; this will create a 387 denial of service attack subtly different from one where only the 388 addresses are forged. Because it is limited to a single flow 389 definition, e.g., to a limited amount of bandwidth, such an attack 390 will be more specific and at a finer granularity than a normal 391 address-spoofing attack. 393 Since flows are identified by the complete 3-tuple, ingress filtering 394 [RFC2827] will, as noted above, mitigate part of the risk. If the 395 source address of a packet is validated by ingress filtering, there 396 can be a degree of trust that the packet has not transited a 397 compromised router, to the extent that ISP infrastructure may be 398 trusted. However, this gives no assurance that another form of man- 399 in-the-middle attack has not occurred. 401 Only applications with an appropriate privilege in a sending host 402 will be entitled to set a non-zero Flow Label. Mechanisms for this 403 are operating system dependent. Related policy and authorization 404 mechanisms may also be required; for example, in a multi-user host, 405 only some users may be entitled to set the Flow Label. Such 406 authorization issues are outside the scope of this specification. 408 6.2. IPsec and Tunneling Interactions 410 The IPsec protocol, as defined in [RFC4301], [RFC4302], [RFC4303] 411 does not include the IPv6 header's Flow Label in any of its 412 cryptographic calculations (in the case of tunnel mode, it is the 413 outer IPv6 header's Flow Label that is not included). Hence 414 modification of the Flow Label by a network node has no effect on 415 IPsec end-to-end security, because it cannot cause any IPsec 416 integrity check to fail. As a consequence, IPsec does not provide 417 any defense against an adversary's modification of the Flow Label 418 (i.e., a man-in-the-middle attack). 420 IPsec tunnel mode provides security for the encapsulated IP header's 421 Flow Label. A tunnel mode IPsec packet contains two IP headers: an 422 outer header supplied by the tunnel ingress node and an encapsulated 423 inner header supplied by the original source of the packet. When an 424 IPsec tunnel is passing through nodes performing flow classification, 425 the intermediate network nodes operate on the Flow Label in the outer 426 header. At the tunnel egress node, IPsec processing includes 427 removing the outer header and forwarding the packet (if required) 428 using the inner header. The IPsec protocol requires that the inner 429 header's Flow Label not be changed by this decapsulation processing 430 to ensure that modifications to label cannot be used to launch theft- 431 or denial-of-service attacks across an IPsec tunnel endpoint. This 432 document makes no change to that requirement; indeed it forbids 433 changes to the Flow Label. 435 When IPsec tunnel egress decapsulation processing includes a 436 sufficiently strong cryptographic integrity check of the encapsulated 437 packet (where sufficiency is determined by local security policy), 438 the tunnel egress node can safely assume that the Flow Label in the 439 inner header has the same value as it had at the tunnel ingress node. 441 This analysis and its implications apply to any tunneling protocol 442 that performs integrity checks. Of course, any Flow Label set in an 443 encapsulating IPv6 header is subject to the risks described in the 444 previous section. 446 6.3. Security Filtering Interactions 448 The Flow Label does nothing to eliminate the need for packet 449 filtering based on headers past the IP header, if such filtering is 450 deemed necessary for security reasons on nodes such as firewalls or 451 filtering routers. 453 However, security devices that clear or rewrite non-zero flow label 454 values would be in violation of this specification. 456 7. IANA Considerations 458 This document requests no action by IANA. 460 8. Acknowledgements 462 Steve Deering and Alex Conta were co-authors of RFC 3697, on which 463 this document is based. 465 Valuable comments and contributions were made by Fred Baker, Steve 466 Blake, Remi Despres, Alan Ford, Fernando Gont, Brian Haberman, Tony 467 Hain, Joel Halpern, Qinwen Hu, Chris Morrow, Thomas Narten, Mark 468 Smith, Pascal Thubert, Iljitsch van Beijnum, and other participants 469 in the 6man working group. 471 Contributors to the development of RFC 3697 included Ran Atkinson, 472 Steve Blake, Jim Bound, Francis Dupont, Robert Elz, Tony Hain, Robert 473 Hancock, Bob Hinden, Christian Huitema, Frank Kastenholz, Thomas 474 Narten, Charles Perkins, Pekka Savola, Hesham Soliman, Michael 475 Thomas, Margaret Wasserman, and Alex Zinin. 477 This document was produced using the xml2rfc tool [RFC2629]. 479 9. Change log 481 draft-ietf-6man-flow-3697bis-00: original version, built from RFC3697 482 and draft-ietf-6man-flow-update-01, 2011-01-31 484 10. References 486 10.1. Normative References 488 [I-D.gont-6man-flowlabel-security] 489 Gont, F., "Security Assessment of the IPv6 Flow Label", 490 draft-gont-6man-flowlabel-security-01 (work in progress), 491 November 2010. 493 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 494 Requirement Levels", BCP 14, RFC 2119, March 1997. 496 [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. 497 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 498 Functional Specification", RFC 2205, September 1997. 500 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 501 (IPv6) Specification", RFC 2460, December 1998. 503 10.2. Informative References 505 [I-D.ietf-6man-flow-update] 506 Amante, S., Carpenter, B., and S. Jiang, "Update to the 507 IPv6 flow label specification", 508 draft-ietf-6man-flow-update-01 (work in progress), 509 January 2011. 511 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 512 June 1999. 514 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 515 Defeating Denial of Service Attacks which employ IP Source 516 Address Spoofing", BCP 38, RFC 2827, May 2000. 518 [RFC3697] Rajahalme, J., Conta, A., Carpenter, B., and S. Deering, 519 "IPv6 Flow Label Specification", RFC 3697, March 2004. 521 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 522 Internet Protocol", RFC 4301, December 2005. 524 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, 525 December 2005. 527 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 528 RFC 4303, December 2005. 530 Authors' Addresses 532 Shane Amante 533 Level 3 Communications, LLC 534 1025 Eldorado Blvd 535 Broomfield, CO 80021 536 USA 538 Email: shane@level3.net 540 Brian Carpenter 541 Department of Computer Science 542 University of Auckland 543 PB 92019 544 Auckland, 1142 545 New Zealand 547 Email: brian.e.carpenter@gmail.com 549 Sheng Jiang 550 Huawei Technologies Co., Ltd 551 Huawei Building, No.3 Xinxi Rd., 552 Shang-Di Information Industry Base, Hai-Dian District, Beijing 553 P.R. China 555 Email: shengjiang@huawei.com 556 Jarno Rajahalme 557 Nokia-Siemens Networks 558 TBD 559 TBD 560 Finland 562 Email: jarno.rajahalme@nsn.com