idnits 2.17.1 draft-matsuhira-mslb-12.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 (4 April 2022) is 751 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group N. Matsuhira 3 Internet-Draft WIDE Project 4 Intended status: Informational 4 April 2022 5 Expires: 6 October 2022 7 Multi-Stage Transparent Server Load Balancing 8 draft-matsuhira-mslb-12 10 Abstract 12 This document specifies Multi-Stage Transparent Server Load Balancing 13 (MSLB) specification. MSLB make server load balancing over Layer3 14 network without packet header change at client and server. MSLB make 15 server load balancing with any protocol and protocol with encription 16 such as IPsec ESP, SSL/TLS. 18 Requirements Language 20 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 21 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 22 document are to be interpreted as described in RFC 2119 [RFC2119]. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at https://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on 6 October 2022. 41 Copyright Notice 43 Copyright (c) 2022 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 48 license-info) in effect on the date of publication of this document. 49 Please review these documents carefully, as they describe your rights 50 and restrictions with respect to this document. Code Components 51 extracted from this document must include Revised BSD License text as 52 described in Section 4.e of the Trust Legal Provisions and are 53 provided without warranty as described in the Revised BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 2. Traditional load balancing method . . . . . . . . . . . . . . 2 59 3. Architecture of MSLB . . . . . . . . . . . . . . . . . . . . 3 60 4. configuration . . . . . . . . . . . . . . . . . . . . . . . . 4 61 4.1. basic configuration . . . . . . . . . . . . . . . . . . . 4 62 4.2. one arm configuration . . . . . . . . . . . . . . . . . . 5 63 5. mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 64 5.1. address translation mode . . . . . . . . . . . . . . . . 6 65 5.2. encapsulation mode . . . . . . . . . . . . . . . . . . . 9 66 6. Ingress filtering environment . . . . . . . . . . . . . . . . 12 67 7. Characteristic . . . . . . . . . . . . . . . . . . . . . . . 13 68 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 69 9. Security Considerations . . . . . . . . . . . . . . . . . . . 14 70 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 71 11. Normative References . . . . . . . . . . . . . . . . . . . . 14 72 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 15 74 1. Introduction 76 This document specifies Multi-Stage Transparent Server Load Balancing 77 (MSLB) specification. 79 MSLB provide server load balancing function over Layer3 network 80 without packet header change at client and server. MSLB work with 81 any protocol and protocol with payload encription such as IPsec ESP, 82 SSL/TLS. 84 2. Traditional load balancing method 86 There are several load balancing technique, such as round robin DNS, 87 IP Anycasting [RFC1546] and destination address translation. 88 Figure 1 shows load balancing system with typical server load 89 balancer with destination address translation technique. 91 +---------+ +--------+ 92 | +---+ Server | 93 +---------+ +----------+ | | +--------+ 94 | | | | | | : 95 +--------+ | | | Server | | | +--------+ 96 | Client +---+ Network +---+ Load +---+ Network +---+ Server | 97 +--------+ | | | Balancer | | | +--------+ 98 | | | | | | : 99 +---------+ +----------+ | | +--------+ 100 | +---+ Server | 101 +---------+ +--------+ 103 Figure 1 105 It is well-known that Network address translator break internet 106 transparency [RFC2775] and have a application dependency [RFC2993] 107 characteristic. 109 Some server load balancer use application data, so with IPsec ESP, 110 SSL/TLS, this mechanisms may not work well. 112 3. Architecture of MSLB 114 Load balancing is the tecnique that distribute packet to multiple 115 server. For packet distribution, destination addresss translation 116 technique is useful, however this technique itself break internet 117 transparency. 119 After distribution, if write back to the original destination address 120 may possoble, it is possible to recover transparency. This is the 121 basic idea and architecture of MSLB. Figure 2 shows architecture of 122 MSLB. 124 Client ---- overwrite +---------- write back ----- server 125 destination | 126 address + --------- write back ----- server 127 | 128 : : : 130 + --------- write back ----- server 132 Figure 2 134 This method process only destination address of IP header. This 135 method can be applied to both IPv4 and IPv6. 137 4. configuration 139 4.1. basic configuration 141 Figure 3 shows basic server load balancing system with MSLB. This 142 case two-stage configuration with one MSLB-F and one-stage many MSLB- 143 Bs. 145 +-------+ +------+ +------+ 146 | +---+MSLB-B+---+Server| 147 +-------+ +------+ | | +------+ +------+ 148 | | | | | | : : 149 +------+ | | | | | | +------+ +------+ 150 |Client+---+Network+---+MSLB-F+---+Network+---+MSLB-B+---+Server| 151 +------+ | | | | | | +------+ +------+ 152 | | | | | | : : 153 +-------+ +------+ | | +------+ +------+ 154 | +---+MSLB-B+---+Server| 155 +-------+ +------+ +------+ 157 Figure 3 159 MSLB-F is front function of MSLB and translate destination address to 160 one of the address of MSLB-B. BSLB-B s backend function of MSLB and 161 translate destination address to the original server address, i.e. 162 address of MSLB-F. The IP address of MSLB-F and all server is the 163 same value. 165 MSLB-F may multi-stage configuration. Figure 4shows three stage 166 configuration with two-stage MSLB-F and one-stage many MSLB-Bs. 168 +---+ +------+ +------+ 169 | |--+MSLB-B+--+Server| 170 +---+ | | +------+ +------+ 171 | | +----+ |Net| : : 172 +---+ +----+ | | |MSLB| | | +------+ +------+ 173 | | | | | |--+ -F +--+ |--+MSLB-B+--+Server| 174 +------+ | | | | | | +----+ +---+ +------+ +------+ 175 |Client+--+Net+--+MSLB+--+Net| 176 +------+ | | | -F | | | +----+ +---+ +------+ +------+ 177 | | | | | +--+MSLB+--+ |--+MSLB-B+--+Server| 178 +---+ +----+ | | | -F | | | +------+ +------+ 179 | | +----+ |Net| : : 180 +---+ | | +------+ +------+ 181 | |--+MSLB-B+--+Server| 182 +---* +------+ +------+ 184 Figure 4 186 4.2. one arm configuration 188 Figure 5shows one arm configuration of server load balancing system 189 with MSLB. 191 +---------+ 192 | | 193 | MSLB-F | 194 | | 195 +----+----+ 196 | 197 +----+----+ +--------+ +--------+ 198 | +---+ MSLB-B +---+ Server | 199 | | +--------+ +--------+ 200 | | : : 201 +--------+ | | +--------+ +--------+ 202 | Client |-----+ Network +---+ MSLB-B +---+ Server | 203 +--------+ | | +--------+ +--------+ 204 | | : : 205 | | +--------+ +--------+ 206 | +---+ MSLB-B +---+ Server | 207 +---------+ +--------+ +--------+ 208 Figure 5 210 MSLB-F is front function of MSLB and translate destination address to 211 one of the address of MSLB-B. BSLB-B s backend function of MSLB and 212 translate destination address to the original server address, i.e. 213 address of MSLB-F. The IP address of MSLB-F and all server is the 214 same value. 216 This configuration, MSLB-F is connecting to the network with single 217 link, that is one arm configuration. This case, retuen packet, i.e. 218 packet from server to client does not pass through the MSLB-F. 220 5. mode 222 MSLB have two mode, one is address translation mode, and the other is 223 encapsulation mode. 225 5.1. address translation mode 227 This mode using address translation technique. 229 Figure Figure 6 shows packet processing with address translation 230 mode. 232 +-------+ +------+ +------+ 233 | +---+MSLB-B+---+Server| 234 +------+ | | | IP_B1| | IP_S | 235 |Client| +-------+ +------+ | | +------+ +------+ 236 | IP_C1+---+ | | | | | 237 +------+ | | | | | | +------+ +------+ 238 |Network| |MSLB-F|---+Network+---+MSLB-B+---+Server| 239 | +---+ | | | | IP_B2| | IP_S | 240 +------+ | | | IP_S | | | +------+ +------+ 241 |Client+---+ | | | | | 242 | IP_C2| +-------+ +------+ | | +------+ +------+ 243 +------+ | +---+MSLB-B+---+Server| 244 | | | IP_B3| | IP_S | 245 +-------+ +------+ +------+ 246 : : 247 : : 248 +------+----+ : +------+----+ :+------+----+ 249 | data | IP | : | data | IP | :| data | IP | 250 +------+----+ : +------+----+ :+------+----+ 251 ----------------------> : --------------------> : ------------> 252 src = IP_C1 : src = IP_C1 : src = IP_C1 253 dst = IP_S : dst = IP_B1 : dst = IP_S 254 : : 255 +------+----+ : +------+----+ :+------+----+ 256 | data | IP | : | data | IP | :| data | IP | 257 +------+----+ : +------+----+ :+------+----+ 258 <--------------------- -: <-------------------- : <------------ 259 src = IP_S : src = IP_S : src = IP_S 260 dst = IP_C1 : dst = IP_C1 : dst = IP_C1 261 : : 263 Figure 6 265 In this figure, to the Client, IP address is allocated IP_C1, IP_C2, 266 and server IP address is IP_S. This case, IP_S is also allocate to 267 all servers and MSLB-F. And to the MSLB-B, IP_B1, IP_B2, IP_B3 is 268 allocated. These allocation is shown in upper part of Figure 6. 270 Lower part of Figure 6 shows packet transfered between client and 271 server. From Client to the Server, only destination address is 272 translate, MSLB-F translate from IP_S to IP_B1, and MSLB-B translate 273 from IP_B1 to IP_S. Then the destination address of packet which 274 send client and the destination address of packet which recieve 275 server is same address. That mean, transparency is remained. 277 Return packet, i.e., from server to the client is not translate, just 278 forwarded. 280 In the Internet, Client IP address and server IP address must Global 281 IP address, however, IP address of MSLB-B may private IP address. 283 +--------------------+----------+-------------------------+ 284 | Source IP address | net mask | destination IP address | 285 +--------------------+----------+-------------------------+ 286 | IP_C1 | | IP_B1 | 287 +--------------------+----------+-------------------------+ 288 | IP_C2 | | IP_B2 | 289 +--------------------+----------+-------------------------+ 290 | : | : | : | 291 | : | : | : | 292 | : | : | : | 293 +--------------------+----------+-------------------------+ 295 Figure 7 297 Figure 7 shows MSLB table. MSLB have this table and translate the 298 destination address using this table value. MSLB-F check source IP 299 address, and translate destination address with this table. 301 Using IPv4-IPv6 translation may possible, i.e., IPv4 packet 302 translated to IPv6, then translate to IPv4 or IPv6 packet translate 303 to IPv4, then translate IPv6 may possibleFigure 8 shows possible 304 combination of IPv4 and IPv6. These IPv4-IPv6 translation case will 305 be defined in future. 307 Client MSLB-F MSLB-B Server 308 : : 309 : : 310 (1) <-- IPv4 --> : <-- IPv4 --> : <-- IPv4 --> 311 : : 312 (2) <-- IPv6 --> : <-- IPv6 --> : <-- IPv6 --> 313 : : 314 (3) <-- IPv4 --> : <-- IPv6 --> : <-- IPv4 --> 315 : : 316 (4) <-- IPv6 --> : <-- IPv4 --> : <-- IPv6 --> 317 : : 319 Figure 8 321 5.2. encapsulation mode 323 This mode using encapsulation technique. 325 Figure Figure 9 shows packet processing with encapsulation mode. 327 +-------+ +------+ +------+ 328 | +---+MSLB-B+---+Server| 329 | | | IP_B1| | IP_S | 330 +-------+ +------+ | | +------+ +------+ 331 | | | | | | 332 +------+ | | | | | | +------+ +------+ 333 |Client|---+Network+---+MSLB-F|---+Network+---+MSLB-B+---+Server| 334 | IP_C | | | | | | | | IP_B2| | IP_S | 335 +------+ | | | IP_S | | | +------+ +------+ 336 | | | | | | 337 +-------+ +------+ | | +------+ +------+ 338 | +---+MSLB-B+---+Server| 339 | | | IP_B3| | IP_S | 340 +-------+ +------+ +------+ 341 : : 342 : : 343 +------+----+ : +------+----+----+ :+------+----+ 344 | data | IP | : | data | IP | IP | :| data | IP | 345 +------+----+ : +------+----+----+ :+------+----+ 346 ----------------------> : --------------------> : ------------> 347 src = IP_C : Inner header : src = IP_C 348 dst = IP_S : src = IP_C : dst = IP_S 349 : dst = IP_S : 350 : Outer header : 351 : src = IP_S : 352 : dst = IP_B1 : 353 : : 354 : : 355 : : 356 +------+----+ : +------+----+ :+------+----+ 357 | data | IP | : | data | IP | :| data | IP | 358 +------+----+ : +------+----+ :+------+----+ 359 <--------------------- -: <-------------------- : <------------ 360 src = IP_S : src = IP_S : src = IP_S 361 dst = IP_C : dst = IP_C : dst = IP_C 362 : : 364 Figure 9 366 In this figure, to the Client, IP address is allocated IP_C1, IP_C2, 367 and server IP address is IP_S. This case, IP_S is also allocate to 368 all servers and MSLB-F. And to the MSLB-B, IP_B1, IP_B2, IP_B3 is 369 allocated. These allocation is shown in upper part of Figure 6. 371 Lower part of Figure 6 shows packet transfered between client and 372 server. From Client to the Server, MSLB-F encapsulate original IP 373 packet and send to MSLB-B. MSLB-B decapsulate outer IP header, and 374 forwarad to the server. Inner IP packet does not change, that mean, 375 transparency is remained. 377 With encapsulation mode, packet size is increase, so fragmentation is 378 needed if encapsulated packet size exceed MTU or Path MTU. MSLB-F 379 MUST support tunnel MTU discovery [RFC1853]. Fragmentation and Path 380 MTU discovery [RFC1191] issue will describe in future. 382 Return packet, i.e., from server to the client is not encapsulate, 383 just forwarded. 385 In the Internet, Client IP address and server IP address must Global 386 IP address, however, IP address of MSLB-B may private IP address. 388 +--------------------+----------+-------------------------+ 389 | Source IP address | net mask | destination IP address | 390 +--------------------+----------+-------------------------+ 391 | IP_C1 | | IP_B1 | 392 +--------------------+----------+-------------------------+ 393 | IP_C2 | | IP_B2 | 394 +--------------------+----------+-------------------------+ 395 | : | : | : | 396 | : | : | : | 397 | : | : | : | 398 +--------------------+----------+-------------------------+ 400 Figure 10 402 Figure 10 shows MSLB table. MSLB have this table and encapsulate and 403 generate outer header with destination address using this table 404 value. MSLB-F check source IP address, and generate destination 405 address of outer header with this table. 407 Using IPv4 over IPv6 encapsulation or IPv6 over IPv4 encapsulation 408 may possible, i.e., IPv4 packet encapsulated to IPv6, then 409 decapsulate to IPv4 or IPv6 packet encapsulated to IPv4, then 410 deencapsulated IPv6 may possibleFigure 11 shows possible combination 411 of IPv4 and IPv6. These IPv4-IPv6 encapsulation case will be defined 412 in future. 414 Client MSLB-F MSLB-B Server 415 : : 416 : : 417 (1) <-- IPv4 --> : <-- IPv4 over IPv4 --> : <-- IPv4 --> 418 : : 419 (2) <-- IPv6 --> : <-- IPv6 over IPv6 --> : <-- IPv6 --> 420 : : 421 (3) <-- IPv4 --> : <-- IPv4 over IPv6 --> : <-- IPv4 --> 422 : : 423 (4) <-- IPv6 --> : <-- IPv6 over IPv4 --> : <-- IPv6 --> 424 : : 426 Figure 11 428 6. Ingress filtering environment 430 [RFC2827] describe ingress filtering for defending DoS attack which 431 employ IP source address spoofing. 433 Depend on the location of the MSLB-F and MSLB-B, it is possible that 434 packet from server to client is discarded by ingress filtering. In 435 such case, encapsulating the packet from server to client might 436 resolve. Figure 12 shows such solution. 438 +-------+ +------+ +------+ 439 | +---+MSLB-B+---+Server| 440 +------+ | | | IP_B1| | IP_S | 441 |Client| +-------+ +------+ | | +------+ +------+ 442 | IP_C1+---+ | | | | | 443 +------+ | | | | | | +------+ +------+ 444 |Network| |MSLB-F|---+Network+---+MSLB-B+---+Server| 445 | +---+ | | | | IP_B2| | IP_S | 446 +------+ | | | IP_S | | | +------+ +------+ 447 |Client+---+ | | | | | 448 | IP_C2| +-------+ +------+ | | +------+ +------+ 449 +------+ | +---+MSLB-B+---+Server| 450 | | | IP_B3| | IP_S | 451 +-------+ +------+ +------+ 453 : : 454 +------+----+ : +------+----+----+ :+------+----+ 455 | data | IP | : | data | IP | IP | :| data | IP | 456 +------+----+ : +------+----+----+ :+------+----+ 457 <--------------------- -: <-------------------- : <------------ 458 src = IP_S : Inner header : src = IP_S 459 dst = IP_C : src = IP_S : dst = IP_C 460 : dst = IP_C : 461 : Outer header : 462 : src = IP_B1 463 : dst = IP_TBD 465 Figure 12 467 7. Characteristic 469 MSLB has following characteristics. 471 * Layer 3 Load balancer 473 * Support NAT unfriendly application such as FTP 475 * work with any application layer protocol (maybe) 476 * work with encription (IPsec ESP, SSL/TLS) 478 * work over Layer 3 network 480 * may enforce policy with static configuration 482 8. IANA Considerations 484 This document makes no request of IANA. 486 Note to RFC Editor: this section may be removed on publication as an 487 RFC. 489 9. Security Considerations 491 Security consideration does not discussed in this memo. 493 10. Acknowledgements 495 11. Normative References 497 [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, 498 DOI 10.17487/RFC1191, November 1990, 499 . 501 [RFC1546] Partridge, C., Mendez, T., and W. Milliken, "Host 502 Anycasting Service", RFC 1546, DOI 10.17487/RFC1546, 503 November 1993, . 505 [RFC1853] Simpson, W., "IP in IP Tunneling", RFC 1853, 506 DOI 10.17487/RFC1853, October 1995, 507 . 509 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 510 Requirement Levels", BCP 14, RFC 2119, 511 DOI 10.17487/RFC2119, March 1997, 512 . 514 [RFC2775] Carpenter, B., "Internet Transparency", RFC 2775, 515 DOI 10.17487/RFC2775, February 2000, 516 . 518 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 519 Defeating Denial of Service Attacks which employ IP Source 520 Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827, 521 May 2000, . 523 [RFC2993] Hain, T., "Architectural Implications of NAT", RFC 2993, 524 DOI 10.17487/RFC2993, November 2000, 525 . 527 Author's Address 529 Naoki Matsuhira 530 WIDE Project 531 Japan 532 Email: naoki.matsuhira@gmail.com