idnits 2.17.1 draft-matsuhira-mslb-09.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 (December 15, 2020) is 1221 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 December 15, 2020 5 Expires: June 18, 2021 7 Multi-Stage Transparent Server Load Balancing 8 draft-matsuhira-mslb-09 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 June 18, 2021. 41 Copyright Notice 43 Copyright (c) 2020 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 (https://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 . . . . . . . . . . . . . . . . . . . . . . . . 2 59 2. Traditional load balancing method . . . . . . . . . . . . . . 2 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 . . . . . . . . . . . . . . . . 12 68 7. Characteristic . . . . . . . . . . . . . . . . . . . . . . . 13 69 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 70 9. Security Considerations . . . . . . . . . . . . . . . . . . . 14 71 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 72 11. Normative References . . . . . . . . . . . . . . . . . . . . 14 73 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 15 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 MSLB- 144 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. 216 address of MSLB-F. The IP address of MSLB-F and all server is the 217 same value. 219 This configuration, MSLB-F is connecting to the network with single 220 link, that is one arm configuration. This case, retuen packet, i.e. 221 packet from server to client does not pass through the MSLB-F. 223 5. mode 225 MSLB have two mode, one is address translation mode, and the other is 226 encapsulation mode. 228 5.1. address translation mode 230 This mode using address translation technique. 232 Figure (Figure 6) shows packet processing with address translation 233 mode. 235 +-------+ +------+ +------+ 236 | +---+MSLB-B+---+Server| 237 +------+ | | | IP_B1| | IP_S | 238 |Client| +-------+ +------+ | | +------+ +------+ 239 | IP_C1+---+ | | | | | 240 +------+ | | | | | | +------+ +------+ 241 |Network| |MSLB-F|---+Network+---+MSLB-B+---+Server| 242 | +---+ | | | | IP_B2| | IP_S | 243 +------+ | | | IP_S | | | +------+ +------+ 244 |Client+---+ | | | | | 245 | IP_C2| +-------+ +------+ | | +------+ +------+ 246 +------+ | +---+MSLB-B+---+Server| 247 | | | IP_B3| | IP_S | 248 +-------+ +------+ +------+ 249 : : 250 : : 251 +------+----+ : +------+----+ :+------+----+ 252 | data | IP | : | data | IP | :| data | IP | 253 +------+----+ : +------+----+ :+------+----+ 254 ----------------------> : --------------------> : ------------> 255 src = IP_C1 : src = IP_C1 : src = IP_C1 256 dst = IP_S : dst = IP_B1 : dst = IP_S 257 : : 258 +------+----+ : +------+----+ :+------+----+ 259 | data | IP | : | data | IP | :| data | IP | 260 +------+----+ : +------+----+ :+------+----+ 261 <--------------------- -: <-------------------- : <------------ 262 src = IP_S : src = IP_S : src = IP_S 263 dst = IP_C1 : dst = IP_C1 : dst = IP_C1 264 : : 266 Figure 6 268 In this figure, to the Client, IP address is allocated IP_C1, IP_C2, 269 and server IP address is IP_S. This case, IP_S is also allocate to 270 all servers and MSLB-F. And to the MSLB-B, IP_B1, IP_B2, IP_B3 is 271 allocated. These allocation is shown in upper part of Figure 6. 273 Lower part of Figure 6 shows packet transfered between client and 274 server. From Client to the Server, only destination address is 275 translate, MSLB-F translate from IP_S to IP_B1, and MSLB-B translate 276 from IP_B1 to IP_S. Then the destination address of packet which 277 send client and the destination address of packet which recieve 278 server is same address. That mean, transparency is remained. 280 Return packet, i.e., from server to the client is not translate, just 281 forwarded. 283 In the Internet, Client IP address and server IP address must Global 284 IP address, however, IP address of MSLB-B may private IP address. 286 +--------------------+----------+-------------------------+ 287 | Source IP address | net mask | destination IP address | 288 +--------------------+----------+-------------------------+ 289 | IP_C1 | | IP_B1 | 290 +--------------------+----------+-------------------------+ 291 | IP_C2 | | IP_B2 | 292 +--------------------+----------+-------------------------+ 293 | : | : | : | 294 | : | : | : | 295 | : | : | : | 296 +--------------------+----------+-------------------------+ 298 Figure 7 300 Figure 7 shows MSLB table. MSLB have this table and translate the 301 destination address using this table value. MSLB-F check source IP 302 address, and translate destination address with this table. 304 Using IPv4-IPv6 translation may possible, i.e., IPv4 packet 305 translated to IPv6, then translate to IPv4 or IPv6 packet translate 306 to IPv4, then translate IPv6 may possibleFigure 8 shows possible 307 combination of IPv4 and IPv6. These IPv4-IPv6 translation case will 308 be defined in future. 310 Client MSLB-F MSLB-B Server 311 : : 312 : : 313 (1) <-- IPv4 --> : <-- IPv4 --> : <-- IPv4 --> 314 : : 315 (2) <-- IPv6 --> : <-- IPv6 --> : <-- IPv6 --> 316 : : 317 (3) <-- IPv4 --> : <-- IPv6 --> : <-- IPv4 --> 318 : : 319 (4) <-- IPv6 --> : <-- IPv4 --> : <-- IPv6 --> 320 : : 322 Figure 8 324 5.2. encapsulation mode 326 This mode using encapsulation technique. 328 Figure Figure 9 shows packet processing with encapsulation mode. 330 +-------+ +------+ +------+ 331 | +---+MSLB-B+---+Server| 332 | | | IP_B1| | IP_S | 333 +-------+ +------+ | | +------+ +------+ 334 | | | | | | 335 +------+ | | | | | | +------+ +------+ 336 |Client|---+Network+---+MSLB-F|---+Network+---+MSLB-B+---+Server| 337 | IP_C | | | | | | | | IP_B2| | IP_S | 338 +------+ | | | IP_S | | | +------+ +------+ 339 | | | | | | 340 +-------+ +------+ | | +------+ +------+ 341 | +---+MSLB-B+---+Server| 342 | | | IP_B3| | IP_S | 343 +-------+ +------+ +------+ 344 : : 345 : : 346 +------+----+ : +------+----+----+ :+------+----+ 347 | data | IP | : | data | IP | IP | :| data | IP | 348 +------+----+ : +------+----+----+ :+------+----+ 349 ----------------------> : --------------------> : ------------> 350 src = IP_C : Inner header : src = IP_C 351 dst = IP_S : src = IP_C : dst = IP_S 352 : dst = IP_S : 353 : Outer header : 354 : src = IP_S : 355 : dst = IP_B1 : 356 : : 357 : : 358 : : 359 +------+----+ : +------+----+ :+------+----+ 360 | data | IP | : | data | IP | :| data | IP | 361 +------+----+ : +------+----+ :+------+----+ 362 <--------------------- -: <-------------------- : <------------ 363 src = IP_S : src = IP_S : src = IP_S 364 dst = IP_C : dst = IP_C : dst = IP_C 365 : : 367 Figure 9 369 In this figure, to the Client, IP address is allocated IP_C1, IP_C2, 370 and server IP address is IP_S. This case, IP_S is also allocate to 371 all servers and MSLB-F. And to the MSLB-B, IP_B1, IP_B2, IP_B3 is 372 allocated. These allocation is shown in upper part of Figure 6. 374 Lower part of Figure 6 shows packet transfered between client and 375 server. From Client to the Server, MSLB-F encapsulate original IP 376 packet and send to MSLB-B. MSLB-B decapsulate outer IP header, and 377 forwarad to the server. Inner IP packet does not change, that mean, 378 transparency is remained. 380 With encapsulation mode, packet size is increase, so fragmentation is 381 needed if encapsulated packet size exceed MTU or Path MTU. MSLB-F 382 MUST support tunnel MTU discovery [RFC1853]. Fragmentation and Path 383 MTU discovery [RFC1191] issue will describe in future. 385 Return packet, i.e., from server to the client is not encapsulate, 386 just forwarded. 388 In the Internet, Client IP address and server IP address must Global 389 IP address, however, IP address of MSLB-B may private IP address. 391 +--------------------+----------+-------------------------+ 392 | Source IP address | net mask | destination IP address | 393 +--------------------+----------+-------------------------+ 394 | IP_C1 | | IP_B1 | 395 +--------------------+----------+-------------------------+ 396 | IP_C2 | | IP_B2 | 397 +--------------------+----------+-------------------------+ 398 | : | : | : | 399 | : | : | : | 400 | : | : | : | 401 +--------------------+----------+-------------------------+ 403 Figure 10 405 Figure 10 shows MSLB table. MSLB have this table and encapsulate and 406 generate outer header with destination address using this table 407 value. MSLB-F check source IP address, and generate destination 408 address of outer header with this table. 410 Using IPv4 over IPv6 encapsulation or IPv6 over IPv4 encapsulation 411 may possible, i.e., IPv4 packet encapsulated to IPv6, then 412 decapsulate to IPv4 or IPv6 packet encapsulated to IPv4, then 413 deencapsulated IPv6 may possibleFigure 11 shows possible combination 414 of IPv4 and IPv6. These IPv4-IPv6 encapsulation case will be defined 415 in future. 417 Client MSLB-F MSLB-B Server 418 : : 419 : : 420 (1) <-- IPv4 --> : <-- IPv4 over IPv4 --> : <-- IPv4 --> 421 : : 422 (2) <-- IPv6 --> : <-- IPv6 over IPv6 --> : <-- IPv6 --> 423 : : 424 (3) <-- IPv4 --> : <-- IPv4 over IPv6 --> : <-- IPv4 --> 425 : : 426 (4) <-- IPv6 --> : <-- IPv6 over IPv4 --> : <-- IPv6 --> 427 : : 429 Figure 11 431 6. Ingress filtering environment 433 [RFC2827] describe ingress filtering for defending DoS attack which 434 employ IP source address spoofing. 436 Depend on the location of the MSLB-F and MSLB-B, it is possible that 437 packet from server to client is discarded by ingress filtering. In 438 such case, encapsulating the packet from server to client might 439 resolve. Figure 12 shows such solution. 441 +-------+ +------+ +------+ 442 | +---+MSLB-B+---+Server| 443 +------+ | | | IP_B1| | IP_S | 444 |Client| +-------+ +------+ | | +------+ +------+ 445 | IP_C1+---+ | | | | | 446 +------+ | | | | | | +------+ +------+ 447 |Network| |MSLB-F|---+Network+---+MSLB-B+---+Server| 448 | +---+ | | | | IP_B2| | IP_S | 449 +------+ | | | IP_S | | | +------+ +------+ 450 |Client+---+ | | | | | 451 | IP_C2| +-------+ +------+ | | +------+ +------+ 452 +------+ | +---+MSLB-B+---+Server| 453 | | | IP_B3| | IP_S | 454 +-------+ +------+ +------+ 456 : : 457 +------+----+ : +------+----+----+ :+------+----+ 458 | data | IP | : | data | IP | IP | :| data | IP | 459 +------+----+ : +------+----+----+ :+------+----+ 460 <--------------------- -: <-------------------- : <------------ 461 src = IP_S : Inner header : src = IP_S 462 dst = IP_C : src = IP_S : dst = IP_C 463 : dst = IP_C : 464 : Outer header : 465 : src = IP_B1 466 : dst = IP_TBD 468 Figure 12 470 7. Characteristic 472 MSLB has following characteristics. 474 o Layer 3 Load balancer 476 o Support NAT unfriendly application such as FTP 478 o work with any application layer protocol (maybe) 480 o work with encription (IPsec ESP, SSL/TLS) 482 o work over Layer 3 network 484 o may enforce policy with static configuration 486 8. IANA Considerations 488 This document makes no request of IANA. 490 Note to RFC Editor: this section may be removed on publication as an 491 RFC. 493 9. Security Considerations 495 Security consideration does not discussed in this memo. 497 10. Acknowledgements 499 11. Normative References 501 [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, 502 DOI 10.17487/RFC1191, November 1990, 503 . 505 [RFC1546] Partridge, C., Mendez, T., and W. Milliken, "Host 506 Anycasting Service", RFC 1546, DOI 10.17487/RFC1546, 507 November 1993, . 509 [RFC1853] Simpson, W., "IP in IP Tunneling", RFC 1853, 510 DOI 10.17487/RFC1853, October 1995, 511 . 513 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 514 Requirement Levels", BCP 14, RFC 2119, 515 DOI 10.17487/RFC2119, March 1997, 516 . 518 [RFC2775] Carpenter, B., "Internet Transparency", RFC 2775, 519 DOI 10.17487/RFC2775, February 2000, 520 . 522 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 523 Defeating Denial of Service Attacks which employ IP Source 524 Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827, 525 May 2000, . 527 [RFC2993] Hain, T., "Architectural Implications of NAT", RFC 2993, 528 DOI 10.17487/RFC2993, November 2000, 529 . 531 Author's Address 533 Naoki Matsuhira 534 Fujitsu Limited 535 17-25, Shinkamata 1-chome, Ota-ku 536 Tokyo 144-8588 537 Japan 539 Phone: +81-3-3735-1111 540 Email: matsuhira@fujitsu.com