idnits 2.17.1 draft-matsuhira-mslb-10.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 (June 18, 2021) is 1041 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 Fujitsu Limited 4 Intended status: Informational June 18, 2021 5 Expires: December 20, 2021 7 Multi-Stage Transparent Server Load Balancing 8 draft-matsuhira-mslb-10 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 http://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 December 20, 2021. 41 Copyright Notice 43 Copyright (c) 2021 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 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Traditional load balancing method . . . . . . . . . . . . . . 3 60 3. Architecture of MSLB . . . . . . . . . . . . . . . . . . . . . 3 61 4. configuration . . . . . . . . . . . . . . . . . . . . . . . . 4 62 4.1. basic configuration . . . . . . . . . . . . . . . . . . . 4 63 4.2. one arm configuration . . . . . . . . . . . . . . . . . . 5 64 5. mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 65 5.1. address translation mode . . . . . . . . . . . . . . . . . 6 66 5.2. encapsulation mode . . . . . . . . . . . . . . . . . . . . 9 67 6. Ingress filtering environment . . . . . . . . . . . . . . . . 11 68 7. Characteristic . . . . . . . . . . . . . . . . . . . . . . . . 12 69 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 70 9. Security Considerations . . . . . . . . . . . . . . . . . . . 13 71 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 72 11. Normative References . . . . . . . . . . . . . . . . . . . . . 13 73 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14 75 1. Introduction 77 This document specifies Multi-Stage Transparent Server Load Balancing 78 (MSLB) specification. 80 MSLB provide server load balancing function over Layer3 network 81 without packet header change at client and server. MSLB work with 82 any protocol and protocol with payload encription such as IPsec ESP, 83 SSL/TLS. 85 2. Traditional load balancing method 87 There are several load balancing technique, such as round robin DNS, 88 IP Anycasting [RFC1546] and destination address translation. 89 Figure 1 shows load balancing system with typical server load 90 balancer with destination address translation technique. 92 +---------+ +--------+ 93 | +---+ Server | 94 +---------+ +----------+ | | +--------+ 95 | | | | | | : 96 +--------+ | | | Server | | | +--------+ 97 | Client +---+ Network +---+ Load +---+ Network +---+ Server | 98 +--------+ | | | Balancer | | | +--------+ 99 | | | | | | : 100 +---------+ +----------+ | | +--------+ 101 | +---+ Server | 102 +---------+ +--------+ 104 Figure 1 106 It is well-known that Network address translator break internet 107 transparency [RFC2775] and have a application dependency [RFC2993] 108 characteristic. 110 Some server load balancer use application data, so with IPsec ESP, 111 SSL/TLS, this mechanisms may not work well. 113 3. Architecture of MSLB 115 Load balancing is the tecnique that distribute packet to multiple 116 server. For packet distribution, destination addresss translation 117 technique is useful, however this technique itself break internet 118 transparency. 120 After distribution, if write back to the original destination address 121 may possoble, it is possible to recover transparency. This is the 122 basic idea and architecture of MSLB. Figure 2 shows architecture of 123 MSLB. 125 Client ---- overwrite +---------- write back ----- server 126 destination | 127 address + --------- write back ----- server 128 | 129 : : : 131 + --------- write back ----- server 133 Figure 2 135 This method process only destination address of IP header. This 136 method can be applied to both IPv4 and IPv6. 138 4. configuration 140 4.1. basic configuration 142 Figure 3 shows basic server load balancing system with MSLB. This 143 case two-stage configuration with one MSLB-F and one-stage many 144 MSLB-Bs. 146 +-------+ +------+ +------+ 147 | +---+MSLB-B+---+Server| 148 +-------+ +------+ | | +------+ +------+ 149 | | | | | | : : 150 +------+ | | | | | | +------+ +------+ 151 |Client+---+Network+---+MSLB-F+---+Network+---+MSLB-B+---+Server| 152 +------+ | | | | | | +------+ +------+ 153 | | | | | | : : 154 +-------+ +------+ | | +------+ +------+ 155 | +---+MSLB-B+---+Server| 156 +-------+ +------+ +------+ 158 Figure 3 160 MSLB-F is front function of MSLB and translate destination address to 161 one of the address of MSLB-B. BSLB-B s backend function of MSLB and 162 translate destination address to the original server address, i.e. 163 address of MSLB-F. The IP address of MSLB-F and all server is the 164 same value. 166 MSLB-F may multi-stage configuration. Figure 4shows three stage 167 configuration with two-stage MSLB-F and one-stage many MSLB-Bs. 169 +---+ +------+ +------+ 170 | |--+MSLB-B+--+Server| 171 +---+ | | +------+ +------+ 172 | | +----+ |Net| : : 173 +---+ +----+ | | |MSLB| | | +------+ +------+ 174 | | | | | |--+ -F +--+ |--+MSLB-B+--+Server| 175 +------+ | | | | | | +----+ +---+ +------+ +------+ 176 |Client+--+Net+--+MSLB+--+Net| 177 +------+ | | | -F | | | +----+ +---+ +------+ +------+ 178 | | | | | +--+MSLB+--+ |--+MSLB-B+--+Server| 179 +---+ +----+ | | | -F | | | +------+ +------+ 180 | | +----+ |Net| : : 181 +---+ | | +------+ +------+ 182 | |--+MSLB-B+--+Server| 183 +---* +------+ +------+ 185 Figure 4 187 4.2. one arm configuration 189 Figure 5shows one arm configuration of server load balancing system 190 with MSLB. 192 +---------+ 193 | | 194 | MSLB-F | 195 | | 196 +----+----+ 197 | 198 +----+----+ +--------+ +--------+ 199 | +---+ MSLB-B +---+ Server | 200 | | +--------+ +--------+ 201 | | : : 202 +--------+ | | +--------+ +--------+ 203 | Client |-----+ Network +---+ MSLB-B +---+ Server | 204 +--------+ | | +--------+ +--------+ 205 | | : : 206 | | +--------+ +--------+ 207 | +---+ MSLB-B +---+ Server | 208 +---------+ +--------+ +--------+ 210 Figure 5 212 MSLB-F is front function of MSLB and translate destination address to 213 one of the address of MSLB-B. BSLB-B s backend function of MSLB and 214 translate destination address to the original server address, i.e. 215 address of MSLB-F. The IP address of MSLB-F and all server is the 216 same value. 218 This configuration, MSLB-F is connecting to the network with single 219 link, that is one arm configuration. This case, retuen packet, i.e. 220 packet from server to client does not pass through the MSLB-F. 222 5. mode 224 MSLB have two mode, one is address translation mode, and the other is 225 encapsulation mode. 227 5.1. address translation mode 229 This mode using address translation technique. 231 Figure Figure 6 shows packet processing with address translation 232 mode. 234 +-------+ +------+ +------+ 235 | +---+MSLB-B+---+Server| 236 +------+ | | | IP_B1| | IP_S | 237 |Client| +-------+ +------+ | | +------+ +------+ 238 | IP_C1+---+ | | | | | 239 +------+ | | | | | | +------+ +------+ 240 |Network| |MSLB-F|---+Network+---+MSLB-B+---+Server| 241 | +---+ | | | | IP_B2| | IP_S | 242 +------+ | | | IP_S | | | +------+ +------+ 243 |Client+---+ | | | | | 244 | IP_C2| +-------+ +------+ | | +------+ +------+ 245 +------+ | +---+MSLB-B+---+Server| 246 | | | IP_B3| | IP_S | 247 +-------+ +------+ +------+ 248 : : 249 : : 250 +------+----+ : +------+----+ :+------+----+ 251 | data | IP | : | data | IP | :| data | IP | 252 +------+----+ : +------+----+ :+------+----+ 253 ----------------------> : --------------------> : ------------> 254 src = IP_C1 : src = IP_C1 : src = IP_C1 255 dst = IP_S : dst = IP_B1 : dst = IP_S 256 : : 257 +------+----+ : +------+----+ :+------+----+ 258 | data | IP | : | data | IP | :| data | IP | 259 +------+----+ : +------+----+ :+------+----+ 260 <--------------------- -: <-------------------- : <------------ 261 src = IP_S : src = IP_S : src = IP_S 262 dst = IP_C1 : dst = IP_C1 : dst = IP_C1 263 : : 265 Figure 6 267 In this figure, to the Client, IP address is allocated IP_C1, IP_C2, 268 and server IP address is IP_S. This case, IP_S is also allocate to 269 all servers and MSLB-F. And to the MSLB-B, IP_B1, IP_B2, IP_B3 is 270 allocated. These allocation is shown in upper part of Figure 6. 272 Lower part of Figure 6 shows packet transfered between client and 273 server. From Client to the Server, only destination address is 274 translate, MSLB-F translate from IP_S to IP_B1, and MSLB-B translate 275 from IP_B1 to IP_S. Then the destination address of packet which send 276 client and the destination address of packet which recieve server is 277 same address. That mean, transparency is remained. 279 Return packet, i.e., from server to the client is not translate, just 280 forwarded. 282 In the Internet, Client IP address and server IP address must Global 283 IP address, however, IP address of MSLB-B may private IP address. 285 +--------------------+----------+-------------------------+ 286 | Source IP address | net mask | destination IP address | 287 +--------------------+----------+-------------------------+ 288 | IP_C1 | | IP_B1 | 289 +--------------------+----------+-------------------------+ 290 | IP_C2 | | IP_B2 | 291 +--------------------+----------+-------------------------+ 292 | : | : | : | 293 | : | : | : | 294 | : | : | : | 295 +--------------------+----------+-------------------------+ 297 Figure 7 299 Figure 7 shows MSLB table. MSLB have this table and translate the 300 destination address using this table value. MSLB-F check source IP 301 address, and translate destination address with this table. 303 Using IPv4-IPv6 translation may possible, i.e., IPv4 packet 304 translated to IPv6, then translate to IPv4 or IPv6 packet translate 305 to IPv4, then translate IPv6 may possibleFigure 8 shows possible 306 combination of IPv4 and IPv6. These IPv4-IPv6 translation case will 307 be defined in future. 309 Client MSLB-F MSLB-B Server 310 : : 311 : : 312 (1) <-- IPv4 --> : <-- IPv4 --> : <-- IPv4 --> 313 : : 314 (2) <-- IPv6 --> : <-- IPv6 --> : <-- IPv6 --> 315 : : 316 (3) <-- IPv4 --> : <-- IPv6 --> : <-- IPv4 --> 317 : : 318 (4) <-- IPv6 --> : <-- IPv4 --> : <-- IPv6 --> 319 : : 321 Figure 8 323 5.2. encapsulation mode 325 This mode using encapsulation technique. 327 Figure Figure 9 shows packet processing with encapsulation mode. 329 +-------+ +------+ +------+ 330 | +---+MSLB-B+---+Server| 331 | | | IP_B1| | IP_S | 332 +-------+ +------+ | | +------+ +------+ 333 | | | | | | 334 +------+ | | | | | | +------+ +------+ 335 |Client|---+Network+---+MSLB-F|---+Network+---+MSLB-B+---+Server| 336 | IP_C | | | | | | | | IP_B2| | IP_S | 337 +------+ | | | IP_S | | | +------+ +------+ 338 | | | | | | 339 +-------+ +------+ | | +------+ +------+ 340 | +---+MSLB-B+---+Server| 341 | | | IP_B3| | IP_S | 342 +-------+ +------+ +------+ 343 : : 344 : : 345 +------+----+ : +------+----+----+ :+------+----+ 346 | data | IP | : | data | IP | IP | :| data | IP | 347 +------+----+ : +------+----+----+ :+------+----+ 348 ----------------------> : --------------------> : ------------> 349 src = IP_C : Inner header : src = IP_C 350 dst = IP_S : src = IP_C : dst = IP_S 351 : dst = IP_S : 352 : Outer header : 353 : src = IP_S : 354 : dst = IP_B1 : 355 : : 356 : : 357 : : 358 +------+----+ : +------+----+ :+------+----+ 359 | data | IP | : | data | IP | :| data | IP | 360 +------+----+ : +------+----+ :+------+----+ 361 <--------------------- -: <-------------------- : <------------ 362 src = IP_S : src = IP_S : src = IP_S 363 dst = IP_C : dst = IP_C : dst = IP_C 364 : : 366 Figure 9 368 In this figure, to the Client, IP address is allocated IP_C1, IP_C2, 369 and server IP address is IP_S. This case, IP_S is also allocate to 370 all servers and MSLB-F. And to the MSLB-B, IP_B1, IP_B2, IP_B3 is 371 allocated. These allocation is shown in upper part of Figure 6. 373 Lower part of Figure 6 shows packet transfered between client and 374 server. From Client to the Server, MSLB-F encapsulate original IP 375 packet and send to MSLB-B. MSLB-B decapsulate outer IP header, and 376 forwarad to the server. Inner IP packet does not change, that mean, 377 transparency is remained. 379 With encapsulation mode, packet size is increase, so fragmentation is 380 needed if encapsulated packet size exceed MTU or Path MTU. MSLB-F 381 MUST support tunnel MTU discovery [RFC1853]. Fragmentation and Path 382 MTU discovery [RFC1191] issue will describe in future. 384 Return packet, i.e., from server to the client is not encapsulate, 385 just forwarded. 387 In the Internet, Client IP address and server IP address must Global 388 IP address, however, IP address of MSLB-B may private IP address. 390 +--------------------+----------+-------------------------+ 391 | Source IP address | net mask | destination IP address | 392 +--------------------+----------+-------------------------+ 393 | IP_C1 | | IP_B1 | 394 +--------------------+----------+-------------------------+ 395 | IP_C2 | | IP_B2 | 396 +--------------------+----------+-------------------------+ 397 | : | : | : | 398 | : | : | : | 399 | : | : | : | 400 +--------------------+----------+-------------------------+ 402 Figure 10 404 Figure 10 shows MSLB table. MSLB have this table and encapsulate and 405 generate outer header with destination address using this table 406 value. MSLB-F check source IP address, and generate destination 407 address of outer header with this table. 409 Using IPv4 over IPv6 encapsulation or IPv6 over IPv4 encapsulation 410 may possible, i.e., IPv4 packet encapsulated to IPv6, then 411 decapsulate to IPv4 or IPv6 packet encapsulated to IPv4, then 412 deencapsulated IPv6 may possibleFigure 11 shows possible combination 413 of IPv4 and IPv6. These IPv4-IPv6 encapsulation case will be defined 414 in future. 416 Client MSLB-F MSLB-B Server 417 : : 418 : : 419 (1) <-- IPv4 --> : <-- IPv4 over IPv4 --> : <-- IPv4 --> 420 : : 421 (2) <-- IPv6 --> : <-- IPv6 over IPv6 --> : <-- IPv6 --> 422 : : 423 (3) <-- IPv4 --> : <-- IPv4 over IPv6 --> : <-- IPv4 --> 424 : : 425 (4) <-- IPv6 --> : <-- IPv6 over IPv4 --> : <-- IPv6 --> 426 : : 428 Figure 11 430 6. Ingress filtering environment 432 [RFC2827] describe ingress filtering for defending DoS attack which 433 employ IP source address spoofing. 435 Depend on the location of the MSLB-F and MSLB-B, it is possible that 436 packet from server to client is discarded by ingress filtering. In 437 such case, encapsulating the packet from server to client might 438 resolve. Figure 12 shows such solution. 440 +-------+ +------+ +------+ 441 | +---+MSLB-B+---+Server| 442 +------+ | | | IP_B1| | IP_S | 443 |Client| +-------+ +------+ | | +------+ +------+ 444 | IP_C1+---+ | | | | | 445 +------+ | | | | | | +------+ +------+ 446 |Network| |MSLB-F|---+Network+---+MSLB-B+---+Server| 447 | +---+ | | | | IP_B2| | IP_S | 448 +------+ | | | IP_S | | | +------+ +------+ 449 |Client+---+ | | | | | 450 | IP_C2| +-------+ +------+ | | +------+ +------+ 451 +------+ | +---+MSLB-B+---+Server| 452 | | | IP_B3| | IP_S | 453 +-------+ +------+ +------+ 455 : : 456 +------+----+ : +------+----+----+ :+------+----+ 457 | data | IP | : | data | IP | IP | :| data | IP | 458 +------+----+ : +------+----+----+ :+------+----+ 459 <--------------------- -: <-------------------- : <------------ 460 src = IP_S : Inner header : src = IP_S 461 dst = IP_C : src = IP_S : dst = IP_C 462 : dst = IP_C : 463 : Outer header : 464 : src = IP_B1 465 : dst = IP_TBD 467 Figure 12 469 7. Characteristic 471 MSLB has following characteristics. 473 o Layer 3 Load balancer 475 o Support NAT unfriendly application such as FTP 477 o work with any application layer protocol (maybe) 479 o work with encription (IPsec ESP, SSL/TLS) 481 o work over Layer 3 network 482 o may enforce policy with static configuration 484 8. IANA Considerations 486 This document makes no request of IANA. 488 Note to RFC Editor: this section may be removed on publication as an 489 RFC. 491 9. Security Considerations 493 Security consideration does not discussed in this memo. 495 10. Acknowledgements 497 11. Normative References 499 [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, 500 DOI 10.17487/RFC1191, November 1990, 501 . 503 [RFC1546] Partridge, C., Mendez, T., and W. Milliken, "Host 504 Anycasting Service", RFC 1546, DOI 10.17487/RFC1546, 505 November 1993, . 507 [RFC1853] Simpson, W., "IP in IP Tunneling", RFC 1853, DOI 10.17487/ 508 RFC1853, October 1995, 509 . 511 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 512 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 513 RFC2119, March 1997, 514 . 516 [RFC2775] Carpenter, B., "Internet Transparency", RFC 2775, 517 DOI 10.17487/RFC2775, February 2000, 518 . 520 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 521 Defeating Denial of Service Attacks which employ IP Source 522 Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827, 523 May 2000, . 525 [RFC2993] Hain, T., "Architectural Implications of NAT", RFC 2993, 526 DOI 10.17487/RFC2993, November 2000, 527 . 529 Author's Address 531 Naoki Matsuhira 532 Fujitsu Limited 533 17-25, Shinkamata 1-chome, Ota-ku 534 Tokyo, 144-8588 535 Japan 537 Phone: +81-3-3735-1111 538 Fax: 539 Email: naoki.matsuhira@gmail.com