idnits 2.17.1 draft-carpenter-v6ops-label-balance-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 : ---------------------------------------------------------------------------- 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 (October 13, 2011) is 4569 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) -- Obsolete informational reference (is this intentional?): RFC 2629 (Obsoleted by RFC 7749) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 V6OPS B. Carpenter 3 Internet-Draft Univ. of Auckland 4 Intended status: Informational S. Jiang 5 Expires: April 15, 2012 Huawei Technologies Co., Ltd 6 October 13, 2011 8 Using the IPv6 Flow Label for Server Load Balancing 9 draft-carpenter-v6ops-label-balance-00 11 Abstract 13 This document describes how the IPv6 flow label can be used in 14 support of layer 3/4 load balancing for large server farms. 16 Status of this Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF). Note that other groups may also distribute 23 working documents as Internet-Drafts. The list of current Internet- 24 Drafts is at http://datatracker.ietf.org/drafts/current/. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 This Internet-Draft will expire on April 15, 2012. 33 Copyright Notice 35 Copyright (c) 2011 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (http://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. Code Components extracted from this document must 44 include Simplified BSD License text as described in Section 4.e of 45 the Trust Legal Provisions and are provided without warranty as 46 described in the Simplified BSD License. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 2. Role of the Flow Label . . . . . . . . . . . . . . . . . . . . 5 52 3. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 53 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 54 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 55 6. Change log [RFC Editor: Please remove] . . . . . . . . . . . . 7 56 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 57 7.1. Normative References . . . . . . . . . . . . . . . . . . . 7 58 7.2. Informative References . . . . . . . . . . . . . . . . . . 8 59 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 61 1. Introduction 63 The IPv6 flow label has been redefined [I-D.ietf-6man-flow-3697bis] 64 and its use for load balancing in multipath routing has been 65 specified [I-D.ietf-6man-flow-ecmp]. Another scenario in which the 66 flow label could be used is in load balancing for large server farms. 67 This document starts with a brief introduction to load balancing 68 techniques and then describes how the flow label can be used to 69 enhance layer 3/4 flow balancers in particular. 71 Load balancing for server farms is achieved by a variety of methods, 72 often used in combination [Tarreau]. The flow label is not relevant 73 to all of them. Also, the actual load balancing algorithm (the 74 choice of server for a new client session) is irrelevant to this 75 discussion. 77 o The simplest method is simply using the DNS to return different 78 server addresses for a single name such as www.example.com to 79 different users. Typically this is done by rotating the order in 80 which different addresses are listed by the relevant authoritative 81 DNS server, assuming that the client will pick the first one. The 82 flow label can have no impact on this method and it is not 83 discussed further. 84 o Another method, for HTTP servers, is to operate a layer 7 reverse 85 proxy in front of the server farm. The reverse proxy will present 86 a single IP address to the world, communicated to clients by a 87 single AAAA record. For each new client session (an incoming TCP 88 connection and HTTP request), it will pick a particular server and 89 proxy the session to it. Hopefully the act of proxying will be 90 cheap compared to the act of serving the required content. The 91 proxy must retain TCP state and proxy state for the duration of 92 the session. This TCP state could, potentially, include the 93 incoming flow label value. 94 o A component of some load balancing systems is an SSL reverse proxy 95 farm. The individual SSL proxies handle all cryptographic aspects 96 and exchange raw HTTP with the actual servers. Thus, from the 97 load balancing point of view, this really looks just like a server 98 farm, except that it's specialised for HTTPS. Each proxy will 99 retain SSL and TCP and maybe HTTP state for the duration of the 100 session, and the TCP state could potentially include the flow 101 label. 102 o Finally the "front end" of many load balancing systems is a layer 103 3/4 load balancer. In this case, it is the layer 3/4 load 104 balancer whose IP address is published as the primary AAAA record 105 for the service. All client sessions will pass through this 106 device. According to the precise scenario, it will spread new 107 sessions across the actual application servers, across an SSL 108 proxy farm, or across a set of layer 7 proxies. In all cases, the 109 layer 3/4 load balancer has to recognize incoming packets as 110 belonging to new or existing client sessions, and choose the 111 target server or proxy so as to ensure persistence. 'Persistence' 112 is defined as guaranteeing that a given session will run to 113 completion on a single server. The layer 3/4 load balancer, 114 whatever method it uses for forwarding the session, is certain to 115 inspect the source address and the protocol and port numbers in 116 each incoming packet. At the same time, it could inspect and make 117 use of the flow label. 119 Layer 3/4 load balancers use various techniques to actually reach 120 their target server. 121 - All servers are configured with the same IP address, they are 122 all on the same LAN, and the load balancer sends directly to their 123 individual MAC addresses. 124 - Each server has its own IP address, and the balancer uses an IP- 125 in-IP tunnel to reach it. 126 - Each server has its own IP address, and the balancer performs 127 NAPT (address and port translation). 129 The following diagram, inspired by [Tarreau], shows a maximum layout. 131 ___________________________________________ 132 ( ) 133 ( Clients in the Internet ) 134 (___________________________________________) 135 | 136 ------------ 137 | Ingress | 138 | router | 139 ------------ 140 ____________|_____________ 141 | | 142 |DNS-based load splitting| 143 | | 144 ------------ ------------ 145 |L3/L4 ASIC| |L3/L4 ASIC| 146 | balancer | | balancer | 147 ------------ ------------ 148 | load | 149 | spreading | 150 __________|________________________|___________ 151 | | | | 152 ------------ ------------ -------- -------- 153 |HTTP proxy|...|HTTP proxy| | SSL |...| SSL | 154 | balancer | | balancer | | proxy| | proxy| 155 ------------ ------------ -------- -------- 156 ____|_____________|_____________|_________|_____ 157 | | | | | 158 -------- -------- -------- -------- -------- 159 |HTTP | |HTTP | |HTTP | |HTTP | |HTTP | 160 |server| |server| |server| |server| |server| 161 -------- -------- -------- -------- -------- 163 From the previous paragraphs, we can identify several points in this 164 diagram where the flow label may be relevant: 166 1. L3/L4 load balancers. 167 2. SSL proxies. 168 3. HTTP proxies. 170 2. Role of the Flow Label 172 The IPv6 flow label is included in every IPv6 header [RFC2460] and it 173 is defined in [I-D.ietf-6man-flow-3697bis]. According to this 174 definition, it should be set to a constant value for a given traffic 175 flow (such as an HTTP connection), but until the standard is widely 176 implemented it will often be set to the default value of zero. Any 177 device that has access to the IPv6 header has access to the flow 178 label, and it is at a fixed position in every IPv6 packet. In 179 contrast, transport layer information, such as the port numbers, is 180 not always in a fixed position, since it follows any IPv6 extension 181 headers that may be present. Therefore, within the lifetime of a 182 given transport layer connection, the flow label can be a more 183 convenient "handle" than the port number for identifying that 184 particular connection. 186 According to [I-D.ietf-6man-flow-3697bis], source hosts should set 187 the flow label, but if they do not (i.e. its value is zero), 188 forwarding nodes may do so instead. In both cases, the flow label 189 value must be constant for a given transport session, normally 190 identified by the IPv6 and Transport header 5-tuple. The flow label 191 should be calculated by a stateless algorithm. The value should form 192 part of a statistically uniform distribution, making it suitable as 193 part of a hash function used for load distribution. Because of using 194 a stateless algorithm to calculate the label, there is a very low 195 (but non-zero) probability that two simultaneous flows from the same 196 source to the same destination have the same flow label value despite 197 having different transport protocol port numbers. 199 The suggested model for using the flow label in a load balancing 200 mechanism is as follows. 202 o It is clearly better if the original source, e.g. an HTTP client, 203 sets the flow label. However, if the flow label of an incoming 204 packet is zero, the ingress router at the server site should 205 implement the stateless mechanism in Section 3 of 206 [I-D.ietf-6man-flow-3697bis] to set the flow label value to an 207 appropriate value. This relieves the subsequent load balancers of 208 the need to fully analyse the IPv6 and Transport header 5-tuple. 209 o The L3/L4 load balancers use the 2-tuple {source address, flow 210 label} as the session key for whatever load distribution algorithm 211 they support, instead of searching for the transport port number 212 later in the header. This means they can ignore all IPv6 213 extension headers, which should simplify their design and lead to 214 a performance benefit. 215 o The SSL proxies may do the same. However, since they have to 216 process the transport layer in any case, this might not lead to 217 any performance benefit. 218 o The HTTP proxies may do the same. However, since they have to 219 process the transport and application layers in any case, this 220 might not lead to any performance benefit. 222 Note that in the unlikely event of two simultaneous flows from the 223 same source having the same flow label value, the two flows would end 224 up assigned to the same server, where they would be distinguished as 225 normal by their port numbers. Since this would be a statistically 226 rare event, it would not damage the overall load balancing effect. 228 3. Security Considerations 230 Security aspects of the flow label are discussed in 231 [I-D.ietf-6man-flow-3697bis]. As noted there, a malicious source or 232 man-in-the-middle could disturb load balancing by manipulating flow 233 labels. 235 Specifically, [I-D.ietf-6man-flow-3697bis] states that "stateless 236 classifiers should not use the flow label alone to control load 237 distribution, and stateful classifiers should include explicit 238 methods to detect and ignore suspect flow label values." The former 239 point is answered by also using the source address. The latter point 240 is more complex. If the risk is considered serious, the ingress 241 router mentioned above should verify incoming flows with non-zero 242 flow label values. If a flow from a given source address and port 243 number does not have a constant flow label value, it is suspect and 244 should be dropped. 246 4. IANA Considerations 248 This document requests no action by IANA. 250 5. Acknowledgements 252 Valuable comments and contributions were made by 254 This document was produced using the xml2rfc tool [RFC2629]. 256 6. Change log [RFC Editor: Please remove] 258 draft-carpenter-v6ops-label-balance-00: original version, 2011-10-13. 260 7. References 262 7.1. Normative References 264 [I-D.ietf-6man-flow-3697bis] 265 Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme, 266 "IPv6 Flow Label Specification", 267 draft-ietf-6man-flow-3697bis-07 (work in progress), 268 July 2011. 270 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 271 (IPv6) Specification", RFC 2460, December 1998. 273 7.2. Informative References 275 [I-D.ietf-6man-flow-ecmp] 276 Carpenter, B. and S. Amante, "Using the IPv6 flow label 277 for equal cost multipath routing and link aggregation in 278 tunnels", draft-ietf-6man-flow-ecmp-05 (work in progress), 279 July 2011. 281 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 282 June 1999. 284 [Tarreau] Tarreau, W., "Making applications scalable with load 285 balancing", 2006, . 287 Authors' Addresses 289 Brian Carpenter 290 Department of Computer Science 291 University of Auckland 292 PB 92019 293 Auckland, 1142 294 New Zealand 296 Email: brian.e.carpenter@gmail.com 298 Sheng Jiang 299 Huawei Technologies Co., Ltd 300 Q14, Huawei Campus 301 No.156 Beiqing Road 302 Hai-Dian District, Beijing 100095 303 P.R. China 305 Email: jiangsheng@huawei.com