idnits 2.17.00 (12 Aug 2021) /tmp/idnits31433/draft-ietf-intarea-flow-label-balancing-03.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (November 01, 2013) is 3116 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 6434 (Obsoleted by RFC 8504) -- Obsolete informational reference (is this intentional?): RFC 2629 (Obsoleted by RFC 7749) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IntArea B. Carpenter 3 Internet-Draft Univ. of Auckland 4 Intended status: Informational S. Jiang 5 Expires: May 05, 2014 Huawei Technologies Co., Ltd 6 W. Tarreau 7 HAProxy, Inc. 8 November 01, 2013 10 Using the IPv6 Flow Label for Load Balancing in Server Farms 11 draft-ietf-intarea-flow-label-balancing-03 13 Abstract 15 This document describes how the IPv6 flow label as currently 16 specified can be used to enhance layer 3/4 load distribution and 17 balancing for large server farms. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on May 05, 2014. 36 Copyright Notice 38 Copyright (c) 2013 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 2. Summary of Flow Label Specification . . . . . . . . . . . . . 3 55 3. Summary of Server Farm Load Balancing Techniques . . . . . . 4 56 4. Applying the Flow Label to L3/L4 Load Balancing . . . . . . . 7 57 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 58 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 59 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 60 8. Change log [RFC Editor: Please remove] . . . . . . . . . . . 12 61 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 62 9.1. Normative References . . . . . . . . . . . . . . . . . . 12 63 9.2. Informative References . . . . . . . . . . . . . . . . . 13 64 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 66 1. Introduction 68 The IPv6 flow label has been redefined [RFC6437] and is now a 69 recommended IPv6 node requirement [RFC6434]. Its use for load 70 sharing in multipath routing has been specified [RFC6438]. Another 71 scenario in which the flow label could be used is in load 72 distribution for large server farms. Load distribution is a slightly 73 more general term than load balancing, but the latter is more 74 commonly used. In the context of a server farm, both terms refer to 75 mechanisms that distribute the workload of a server farm among 76 different servers in order to optimize performance. Server load 77 balancing commonly applies to HTTP traffic, but most of the 78 techniques described would apply to other upper layer applications as 79 well. This document starts with brief introductions to the flow 80 label and to server load balancing techniques, and then describes how 81 the flow label can be used to enhance load balancers operating on IP 82 packets and TCP sessions, commonly known as layer 3/4 load balancers. 84 The motivation for this approach is to improve the performance of 85 most types of layer 3/4 load balancers, especially for traffic 86 including multiple IPv6 extension headers and in particular for 87 fragmented packets. Fragmented packets, often the result of 88 customers reaching the load balancer via a VPN with a limited MTU, 89 are a common performance problem. 91 2. Summary of Flow Label Specification 93 The IPv6 flow label [RFC6437] is a 20 bit field included in every 94 IPv6 header [RFC2460]. It is recommended to be supported in all IPv6 95 nodes by [RFC6434]. There is additional background material in 96 [RFC6436] and [RFC6294]. According to its definition, the flow label 97 should be set to a constant value for a given traffic flow (such as 98 an HTTP connection), and that value will belong to a uniform 99 statistical distribution, making it potentially valuable for load 100 balancing purposes. 102 Any device that has access to the IPv6 header has access to the flow 103 label, and it is at a fixed position in every IPv6 packet. In 104 contrast, transport layer information, such as the port numbers, is 105 not always in a fixed position, since it follows any IPv6 extension 106 headers that may be present. In fact, the logic of finding the 107 transport header is always more complex for IPv6 than for IPv4, due 108 to the absence of an Internet Header Length field in IPv6. 109 Additionally, if packets are fragmented, the flow label will be 110 present in all fragments, but the transport header will only be in 111 one packet. Therefore, within the lifetime of a given transport 112 layer connection, the flow label can be a more convenient "handle" 113 than the port number for identifying that particular connection. 115 According to RFC 6437, source hosts should set the flow label, but, 116 if they do not (i.e., its value is zero), forwarding nodes (such as 117 the first-hop router) may set it instead. In both cases, the flow 118 label value must be constant for a given transport session, normally 119 identified by the IPv6 and Transport header 5-tuple. By default, the 120 flow label value should be calculated by a stateless algorithm. The 121 resulting value should form part of a statistically uniform 122 distribution, regardless of which node sets it. 124 It is recognised that at the time of writing, very few traffic flows 125 include a non-zero flow label value. The mechanism described below 126 is one that can be added to existing load balancing mechanisms, so 127 that it will become effective as more and more flows contain a non- 128 zero label. Even if the flow label is chosen from an imperfectly 129 uniform distribution, it will nevertheless increase the information 130 entropy of the IPv6 header as a whole. This allows for progressive 131 introduction of load balancing based on the flow label. 133 If the recommendations in Section 3 of RFC 6437 are followed for 134 traffic from a given source accessing a well-known TCP port at a 135 given destination, the flow label can act as a substitute for the 136 port numbers as far as a load balancer is concerned, and it can be 137 found at a fixed position in the layer 3 header even if any extension 138 headers are present. 140 The flow label is defined as an end-to-end component of the IPv6 141 header, but there are three qualifications to this: 143 1. Until the RFC 6437 standard is widely implemented as recommended 144 by RFC 6434, the flow label will often be set to the default 145 value of zero. 147 2. Because of the recommendation to use a stateless algorithm to 148 calculate the label, there is a low (but non-zero) probability 149 that two simultaneous flows from the same source to the same 150 destination have the same flow label value despite having 151 different transport protocol port numbers. 153 3. The flow label field is in an unprotected part of the IPv6 154 header, which means that intentional or unintentional changes to 155 its value cannot be easily detected by a receiver. 157 The first two points are addressed below in Section 4 and the third 158 in Section 5. 160 3. Summary of Server Farm Load Balancing Techniques 162 Load balancing for server farms is achieved by a variety of methods, 163 often used in combination [Tarreau]. This section gives a general 164 overview of common methods, although the flow label is not relevant 165 to all of them. The actual load balancing algorithm (the choice of 166 which server to use for a new client session) is irrelevant to this 167 discussion. We give examples for HTTP, but analogous techniques may 168 be used for other application protocols. 170 o The simplest method is simply using the DNS to return different 171 server addresses for a single name such as www.example.com to 172 different users. This is typically done by rotating the order in 173 which different addresses within the server site are listed by the 174 relevant authoritative DNS server, on the assumption that the 175 client will pick the first one. Routing may be configured such 176 that the different addresses are handled by different ingress 177 routers. Several variants of this load balancing mechanism exist, 178 such as expecting some clients to use all the advertised addresses 179 when multiple connections are involved, or directing the traffic 180 to multiple sites, also known as global load balancing. None of 181 these mechanisms are in the scope of this document, and what this 182 document proposes does not affect their usability nor aim to 183 replace them, so they will not be discussed further. 185 o Another method, for HTTP servers, is to operate a layer 7 reverse 186 proxy in front of the server farm. The reverse proxy will present 187 a single IP address to the world, communicated to clients by a 188 single AAAA record. For each new client session (an incoming TCP 189 connection and HTTP request), it will pick a particular server and 190 proxy the session to it. The act of proxying should be more 191 efficient and less resource-intensive than the act of serving the 192 required content. The proxy must retain TCP state and proxy state 193 for the duration of the session. This TCP state could, 194 potentially, include the incoming flow label value. 196 o A component of some load balancing systems is an SSL reverse proxy 197 farm. The individual SSL proxies handle all cryptographic aspects 198 and exchange unencrypted HTTP with the actual servers. Thus, from 199 the load balancing point of view, this really looks just like a 200 server farm, except that it's specialised for HTTPS. Each proxy 201 will retain SSL and TCP and maybe HTTP state for the duration of 202 the session, and the TCP state could potentially include the flow 203 label. 205 o Finally the "front end" of many load balancing systems is a layer 206 3/4 load balancer. While it can be a dedicated device, it is also 207 a standard function of some network switches or routers (e.g. 208 using Equal Cost Multipath Routing (ECMP) [RFC2991]). In this 209 case, it is the layer 3/4 load balancer whose IP address is 210 published as the primary AAAA record for the service. All client 211 sessions will pass through this device. Depending on the specific 212 scenario, the balancer will assign new sessions among the actual 213 application servers, across an SSL proxy farm, or among a set of 214 layer 7 proxies. In all cases, the layer 3/4 load balancer has to 215 classify incoming packets very quickly and choose the target 216 server or proxy so as to ensure persistence. 'Persistence' is 217 defined as the guarantee that a given client session will run to 218 completion on a single server. The layer 3/4 load balancer 219 therefore needs to inspect each incoming packet to classify it. 220 There are two common types of layer 3/4 load balancers, the 221 totally stateless ones which only act on single packets, generally 222 involving a per-packet hashing of easy-to-find information such as 223 the source address and/or port into a server number, and the 224 stateful ones which take the routing decision on the very first 225 packets of a session and maintain the same direction for all 226 packets belonging to the same session. Clearly, both types of 227 layer 3/4 balancers could inspect and make use of the flow label 228 value. 230 Our focus is on how the balancer identifies a particular flow. 231 For clarity, note that two aspects of layer 3/4 load balancers are 232 not affected by use of the flow label to identify sessions: 234 1. Balancers use various techniques to redirect traffic to a 235 specific target server. 237 - All servers are configured with the same IP address, they 238 are all on the same LAN, and the load balancer sends directly 239 to their individual MAC addresses. In this case, return 240 packets from the server to the client are sent back without 241 passing through the balancer, a technique known as direct 242 server return, but we are not concerned here with the return 243 packets. 245 -All servers are configured with the same IP address, treated 246 locally as an anycast address by layer 3 ECMP routing. 248 - Each server has its own IP address, and the balancer uses an 249 IP-in-IP tunnel to reach it. 251 - Each server has its own IP address, and the balancer 252 performs NAPT (network address and port translation) to 253 deliver the client's packets to that address. 255 The choice between these methods is not affected by use of the 256 flow label. 258 2. A layer 3/4 balancer must correctly handle Path MTU Discovery 259 by forwarding relevant ICMPv6 packets in both directions. 260 This too is not directly affected by use of the flow label. 261 It should be noted that there may be difficulty correlating an 262 ICMPv6 "Packet too big" response with the session it refers 263 to, but that is out of the scope of the present document. 265 The following diagram, inspired by [Tarreau], shows a layout with 266 various methods in use together. 268 ___________________________________________ 269 ( ) 270 ( Clients in the Internet ) 271 (___________________________________________) 272 | | 273 ------------ DNS-based ------------ 274 | Ingress | load splitting | Ingress | 275 | router | affects | router | 276 ------------ routing ------------ 277 ___|____________________________|___ 278 | | 279 | | 280 | | 281 ------------ ------------ 282 | L3/4 ASIC| | L3/4 ASIC| 283 | balancer | | balancer | 284 ------------ ------------ 285 | load | 286 | spreading | 287 __________|________________________|___________ 288 | | | | 289 ------------ ------------ -------- -------- 290 |HTTP proxy|...|HTTP proxy| | SSL |...| SSL | 291 | balancer | | balancer | | proxy| | proxy| 292 ------------ ------------ -------- -------- 293 ____|_____________|_____________|_________|_____ 294 | | | | | 295 -------- -------- -------- -------- -------- 296 |HTTP | |HTTP | |HTTP | |HTTP | |HTTP | 297 |server| |server| |server| |server| |server| 298 -------- -------- -------- -------- -------- 300 From the previous paragraphs, we can identify several points in this 301 diagram where the flow label might be relevant: 303 1. Layer 3/4 load balancers. 305 2. SSL proxies. 307 3. HTTP proxies. 309 However, usage by the proxies seems unlikely to affect performance, 310 because they must in any case process the application layer header, 311 so in this document we focus only on layer 3/4 balancers. 313 4. Applying the Flow Label to L3/L4 Load Balancing 315 The suggested model for using the flow label to enhance a L3/L4 load 316 balancing mechanism is as follows: 318 o We are only concerned with IPv6 traffic in which the flow label 319 value has been set according to [RFC6437]. If the flow label of 320 an incoming packet is zero, load balancers will continue to use 321 the transport header in the traditional way. As the use of the 322 flow label becomes more prevalent according to RFC 6434, load 323 balancers, and therefore users, will reap a growing performance 324 benefit. 326 o If the flow label of an incoming packet is non-zero, layer 3/4 327 load balancers can use the 2-tuple {source address, flow label} as 328 the session key for whatever load distribution algorithm they 329 support. Alternatively, they might use the 3-tuple {dest address, 330 source address, flow label}, especially if the server farm 331 supports multiple server IP addresses, but this does not affect 332 the argument. If any IPv6 extension headers, including fragment 333 headers, are present, this will be significantly quicker than 334 searching for the transport port numbers later in the packet. 335 Moreover, the transport layer information such as the source port 336 is not repeated in fragments, which generally prevents stateless 337 load balancers from supporting fragmented traffic since they 338 generally cannot reassemble fragments. 340 A stateless layer 3/4 load balancer would simply apply a hash 341 algorithm to the 2-tuple or 3-tuple on all packets, in order to 342 select the same target server consistently for a given flow. 343 Needless to say, the hash algorithm has to be well chosen for its 344 purpose, but this problem is common to several forms of stateless 345 load balancing. The discussion in [RFC6438] applies. 347 A stateful layer 3/4 load balancer would apply its usual load 348 distribution algorithm to the first packet of a session, and store 349 the {tuple, server} association in a table so that subsequent 350 packets belonging to the same session are forwarded to the same 351 server. Thus, for all subsequent packets of the session, it can 352 ignore all IPv6 extension headers, which should lead to a 353 performance benefit. Whether this benefit is valuable will depend 354 on engineering details of the specific load balancer. 356 Note that such a balancer will not identify new transport sessions 357 from the same source that use the same flow label; they will be 358 delivered to the same server. This is like the behavior of 359 existing hash-based layer 4 balancers that always send similarly 360 hashed packets to the same destination. However, a global state 361 table in a flow label balancer cannot be shared between multiple 362 services if these services rely on transport layer information, 363 since the goal of using the flow label is to avoid looking up that 364 information. 366 A related issue is that the balancer will not detect FIN/ACK 367 sequences at the end of sessions. Therefore, it will rely on 368 inactivity timers to delete session state. However, all existing 369 balancers must maintain such timers to deal with hung sessions, 370 and the practical impact on memory utilisation is unlikely to be 371 significant. 373 o Layer 3/4 balancers that redirect the incoming packets by NAPT are 374 not expected to obtain any saving of time by using the flow label, 375 because they have no choice but to follow the extension header 376 chain, in order to locate and modify the port number and transport 377 checksum. The same would apply to balancers that perform TCP 378 state tracking for any reason. 380 o Note that correct handling of ICMPv6 for Path MTU Discovery 381 requires the layer 3/4 balancer to keep state for the client 382 source address, independently of either the port numbers or the 383 flow label. 385 o SSL and HTTP proxies, if present, should forward the flow label 386 value towards the server. This usually has no performance 387 benefit, but is consistent with the general RFC 6437 model for the 388 flow label. 390 It should be noted that the performance benefit, if any, depends 391 entirely on engineering trade-offs in the design of the L3/L4 392 balancer. An extra test is needed (is the label non-zero?), but if 393 there is a non-zero label, all logic for handling extension headers 394 can be skipped except for the first packet of a new flow. Since the 395 identifying state to be stored is only the tuple and the server 396 identifier, storage requirements will be reduced. Additionally, the 397 method will work for fragmented traffic and for flows where the 398 transport information is missing (unknown transport protocol) or 399 obfuscated (e.g., IPsec). Traffic reaching the load balancer via a 400 VPN is particularly prone to the fragmentation issue, due to MTU size 401 issues. For some load balancer designs, these are very significant 402 advantages. 404 In the unlikely event of two simultaneous flows from the same source 405 address having the same flow label value, the two flows would end up 406 assigned to the same server, where they would be distinguished as 407 normal by their port numbers. There are approximately one million 408 possible flow label values, and if the rules for flow label 409 generation [RFC6437] are followed, this would be a statistically rare 410 event, and would not damage the overall load balancing effect. 411 Moreover, with a million possible label values, it is very likely 412 that there will be many more flow label values than servers at most 413 sites, so it is already expected that multiple flow label values will 414 end up on the same server for a given client IP address. 416 In the case that many thousands of clients are hidden behind the same 417 large-scale NAPT (network address and port translator) with a single 418 shared IP address, the assumption of low probability of conflicts 419 might become incorrect, unless flow label values are random enough to 420 avoid following similar sequences for all clients. This is not 421 expected to be a factor for IPv6 anyway, since there is no need to 422 implement large-scale NAPT with address sharing [RFC4864]. The 423 probability of conflicts is low for sites that implement network 424 prefix translation [RFC6296], since this technique provides a 425 different address for each client. 427 5. Security Considerations 429 Security aspects of the flow label are discussed in [RFC6437]. As 430 noted there, a malicious source or man-in-the-middle could disturb 431 load balancing by manipulating flow labels. This risk already exists 432 today where the source address and port are used as hashing key in 433 layer 3/4 load balancers, as well as where a persistence cookie is 434 used in HTTP to designate a server. It even exists on layer 3 435 components which only rely on the source address to select a 436 destination, making them more DDoS-prone. Nevertheless, all these 437 methods are currently used because the benefits for load balancing 438 and persistence hugely outweigh the risks. The flow label does not 439 significantly alter this situation. 441 Specifically, the standard [RFC6437] states that "stateless 442 classifiers should not use the flow label alone to control load 443 distribution, and stateful classifiers should include explicit 444 methods to detect and ignore suspect flow label values." The former 445 point is answered by also using the source address. The latter point 446 is more complex. If the risk is considered serious, the site ingress 447 router or the layer 3/4 balancer should use a suitable heuristic to 448 verify incoming flows with non-zero flow label values. If a flow 449 from a given source address and port number does not have a constant 450 flow label value, it is suspect and should be dropped. This would 451 deal with both intentional and accidental changes to the flow label. 453 A malicious source or man-in-the-middle could generate a flow in 454 which the flow label is constant but the transport port numbers in 455 some packets are invalid. Such packets, if load-balanced only on the 456 basis of the flow label, could reach the target server and create a 457 single-source DOS attack on its TCP engine. 459 RFC 6437 notes in its Security Considerations that if the covert 460 channel risk is considered significant, a firewall might rewrite non- 461 zero flow labels. As long as this is done as described in RFC 6437, 462 it will not invalidate the mechanisms described above. 464 The flow label may be of use in protecting against distributed denial 465 of service (DDOS) attacks against servers. As noted in RFC 6437, a 466 source should generate flow label values that are hard to predict, 467 most likely by including a secret nonce in the hash used to generate 468 each label. The attacker does not know the nonce and therefore has 469 no way to invent flow labels which will all target the same server, 470 even with knowledge of both the hash algorithm and the load balancing 471 algorithm. Still, it is important to understand that it is always 472 trivial to force a load balancer to stick to the same server during 473 an attack, so the security of the whole solution must not rely on the 474 unpredicatability of the flow label values alone, but should include 475 defensive measures like most load balancers already have against 476 abnormal use of source address or session cookies. 478 New flows are assigned to a server according to any of the usual 479 algorithms available on the load balancer (e.g., least connections, 480 round robin, etc.). The association between the source address/flow 481 label value and the server is stored in a table (often called stick 482 table) so that future traffic from the same source using the same 483 flow label can be sent to the same server. This method is more 484 robust against a loss of server and also makes it harder for an 485 attacker to target a specific server, because the association between 486 a flow label value and a server is not known externally. 488 In the case that a stateless hash function is used to assign client 489 packets to specific servers, it may be advisable to use a 490 cryptographic hash function of some kind, to ensure that an attacker 491 cannot predict the behaviour of the load balancer. 493 6. IANA Considerations 495 This document requests no action by IANA. 497 7. Acknowledgements 499 Valuable comments and contributions were made by Fred Baker, Olivier 500 Bonaventure, Ben Campbell, Lorenzo Colitti, Linda Dunbar, Donald 501 Eastlake, Joel Jaeggli, Gurudeep Kamat, Warren Kumari, Julia 502 Renouard, Julius Volz, and others. 504 This document was produced using the xml2rfc tool [RFC2629]. 506 8. Change log [RFC Editor: Please remove] 508 draft-ietf-intarea-flow-label-balancing-03: IESG comments, 509 2013-11-01. 511 draft-ietf-intarea-flow-label-balancing-02: Last Call comments, 512 2013-10-07. 514 draft-ietf-intarea-flow-label-balancing-01: clarifications based on 515 WG comments, 2013-05-25. 517 draft-ietf-intarea-flow-label-balancing-00: WG adoption, minor WG 518 comments, 2013-01-15. 520 draft-carpenter-flow-label-balancing-02: updates based on external 521 review, 2012-12-05. 523 draft-carpenter-flow-label-balancing-01: update following comments, 524 2012-06-12. 526 draft-carpenter-flow-label-balancing-00: restructured after IETF83, 527 2012-05-08. 529 draft-carpenter-v6ops-label-balance-02: clarified after WG 530 discussions, 2012-03-06. 532 draft-carpenter-v6ops-label-balance-01: updated with community 533 comments, additional author, 2012-01-17. 535 draft-carpenter-v6ops-label-balance-00: original version, 2011-10-13. 537 9. References 539 9.1. Normative References 541 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 542 (IPv6) Specification", RFC 2460, December 1998. 544 [RFC6434] Jankiewicz, E., Loughney, J., and T. Narten, "IPv6 Node 545 Requirements", RFC 6434, December 2011. 547 [RFC6437] Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme, 548 "IPv6 Flow Label Specification", RFC 6437, November 2011. 550 9.2. Informative References 552 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 553 June 1999. 555 [RFC2991] Thaler, D. and C. Hopps, "Multipath Issues in Unicast and 556 Multicast Next-Hop Selection", RFC 2991, November 2000. 558 [RFC4864] Van de Velde, G., Hain, T., Droms, R., Carpenter, B., and 559 E. Klein, "Local Network Protection for IPv6", RFC 4864, 560 May 2007. 562 [RFC6294] Hu, Q. and B. Carpenter, "Survey of Proposed Use Cases for 563 the IPv6 Flow Label", RFC 6294, June 2011. 565 [RFC6296] Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network Prefix 566 Translation", RFC 6296, June 2011. 568 [RFC6436] Amante, S., Carpenter, B., and S. Jiang, "Rationale for 569 Update to the IPv6 Flow Label Specification", RFC 6436, 570 November 2011. 572 [RFC6438] Carpenter, B. and S. Amante, "Using the IPv6 Flow Label 573 for Equal Cost Multipath Routing and Link Aggregation in 574 Tunnels", RFC 6438, November 2011. 576 [Tarreau] Tarreau, W., "Making applications scalable with load 577 balancing", 2006, . 579 Authors' Addresses 581 Brian Carpenter 582 Department of Computer Science 583 University of Auckland 584 PB 92019 585 Auckland 1142 586 New Zealand 588 Email: brian.e.carpenter@gmail.com 589 Sheng Jiang 590 Huawei Technologies Co., Ltd 591 Q14, Huawei Campus 592 No.156 Beiqing Road 593 Hai-Dian District, Beijing 100095 594 P.R. China 596 Email: jiangsheng@huawei.com 598 Willy Tarreau 599 HAProxy, Inc. 600 R&D Network Products 601 3 rue du petit Robinson 602 78350 Jouy-en-Josas 603 France 605 Email: w@1wt.eu