idnits 2.17.1 draft-matsuhira-mslb-08.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 3, 2020) is 1394 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 3, 2020 5 Expires: December 5, 2020 7 Multi-Stage Transparent Server Load Balancing 8 draft-matsuhira-mslb-08 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 5, 2020. 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 (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. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 73 11.1. Normative References . . . . . . . . . . . . . . . . . . . 13 74 11.2. Informative References . . . . . . . . . . . . . . . . . . 14 75 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14 77 1. Introduction 79 This document specifies Multi-Stage Transparent Server Load Balancing 80 (MSLB) specification. 82 MSLB provide server load balancing function over Layer3 network 83 without packet header change at client and server. MSLB work with 84 any protocol and protocol with payload encription such as IPsec ESP, 85 SSL/TLS. 87 2. Traditional load balancing method 89 There are several load balancing technique, such as round robin DNS, 90 IP Anycasting [RFC1546] and destination address translation. 91 Figure 1 shows load balancing system with typical server load 92 balancer with destination address translation technique. 94 +---------+ +--------+ 95 | +---+ Server | 96 +---------+ +----------+ | | +--------+ 97 | | | | | | : 98 +--------+ | | | Server | | | +--------+ 99 | Client +---+ Network +---+ Load +---+ Network +---+ Server | 100 +--------+ | | | Balancer | | | +--------+ 101 | | | | | | : 102 +---------+ +----------+ | | +--------+ 103 | +---+ Server | 104 +---------+ +--------+ 106 Figure 1 108 It is well-known that Network address translator break internet 109 transparency [RFC2775] and have a application dependency [RFC2993] 110 characteristic. 112 Some server load balancer use application data, so with IPsec ESP, 113 SSL/TLS, this mechanisms may not work well. 115 3. Architecture of MSLB 117 Load balancing is the tecnique that distribute packet to multiple 118 server. For packet distribution, destination addresss translation 119 technique is useful, however this technique itself break internet 120 transparency. 122 After distribution, if write back to the original destination address 123 may possoble, it is possible to recover transparency. This is the 124 basic idea and architecture of MSLB. Figure 2 shows architecture of 125 MSLB. 127 Client ---- overwrite +---------- write back ----- server 128 destination | 129 address + --------- write back ----- server 130 | 131 : : : 133 + --------- write back ----- server 135 Figure 2 137 This method process only destination address of IP header. This 138 method can be applied to both IPv4 and IPv6. 140 4. configuration 142 4.1. basic configuration 144 Figure 3 shows basic server load balancing system with MSLB. This 145 case two-stage configuration with one MSLB-F and one-stage many 146 MSLB-Bs. 148 +-------+ +------+ +------+ 149 | +---+MSLB-B+---+Server| 150 +-------+ +------+ | | +------+ +------+ 151 | | | | | | : : 152 +------+ | | | | | | +------+ +------+ 153 |Client+---+Network+---+MSLB-F+---+Network+---+MSLB-B+---+Server| 154 +------+ | | | | | | +------+ +------+ 155 | | | | | | : : 156 +-------+ +------+ | | +------+ +------+ 157 | +---+MSLB-B+---+Server| 158 +-------+ +------+ +------+ 160 Figure 3 162 MSLB-F is front function of MSLB and translate destination address to 163 one of the address of MSLB-B. BSLB-B s backend function of MSLB and 164 translate destination address to the original server address, i.e. 165 address of MSLB-F. The IP address of MSLB-F and all server is the 166 same value. 168 MSLB-F may multi-stage configuration. Figure 4shows three stage 169 configuration with two-stage MSLB-F and one-stage many MSLB-Bs. 171 +---+ +------+ +------+ 172 | |--+MSLB-B+--+Server| 173 +---+ | | +------+ +------+ 174 | | +----+ |Net| : : 175 +---+ +----+ | | |MSLB| | | +------+ +------+ 176 | | | | | |--+ -F +--+ |--+MSLB-B+--+Server| 177 +------+ | | | | | | +----+ +---+ +------+ +------+ 178 |Client+--+Net+--+MSLB+--+Net| 179 +------+ | | | -F | | | +----+ +---+ +------+ +------+ 180 | | | | | +--+MSLB+--+ |--+MSLB-B+--+Server| 181 +---+ +----+ | | | -F | | | +------+ +------+ 182 | | +----+ |Net| : : 183 +---+ | | +------+ +------+ 184 | |--+MSLB-B+--+Server| 185 +---* +------+ +------+ 187 Figure 4 189 4.2. one arm configuration 191 Figure 5shows one arm configuration of server load balancing system 192 with MSLB. 194 +---------+ 195 | | 196 | MSLB-F | 197 | | 198 +----+----+ 199 | 200 +----+----+ +--------+ +--------+ 201 | +---+ MSLB-B +---+ Server | 202 | | +--------+ +--------+ 203 | | : : 204 +--------+ | | +--------+ +--------+ 205 | Client |-----+ Network +---+ MSLB-B +---+ Server | 206 +--------+ | | +--------+ +--------+ 207 | | : : 208 | | +--------+ +--------+ 209 | +---+ MSLB-B +---+ Server | 210 +---------+ +--------+ +--------+ 212 Figure 5 214 MSLB-F is front function of MSLB and translate destination address to 215 one of the address of MSLB-B. BSLB-B s backend function of MSLB and 216 translate destination address to the original server address, i.e. 217 address of MSLB-F. The IP address of MSLB-F and all server is the 218 same value. 220 This configuration, MSLB-F is connecting to the network with single 221 link, that is one arm configuration. This case, retuen packet, i.e. 222 packet from server to client does not pass through the MSLB-F. 224 5. mode 226 MSLB have two mode, one is address translation mode, and the other is 227 encapsulation mode. 229 5.1. address translation mode 231 This mode using address translation technique. 233 Figure Figure 6 shows packet processing with address translation 234 mode. 236 +-------+ +------+ +------+ 237 | +---+MSLB-B+---+Server| 238 +------+ | | | IP_B1| | IP_S | 239 |Client| +-------+ +------+ | | +------+ +------+ 240 | IP_C1+---+ | | | | | 241 +------+ | | | | | | +------+ +------+ 242 |Network| |MSLB-F|---+Network+---+MSLB-B+---+Server| 243 | +---+ | | | | IP_B2| | IP_S | 244 +------+ | | | IP_S | | | +------+ +------+ 245 |Client+---+ | | | | | 246 | IP_C2| +-------+ +------+ | | +------+ +------+ 247 +------+ | +---+MSLB-B+---+Server| 248 | | | IP_B3| | IP_S | 249 +-------+ +------+ +------+ 250 : : 251 : : 252 +------+----+ : +------+----+ :+------+----+ 253 | data | IP | : | data | IP | :| data | IP | 254 +------+----+ : +------+----+ :+------+----+ 255 ----------------------> : --------------------> : ------------> 256 src = IP_C1 : src = IP_C1 : src = IP_C1 257 dst = IP_S : dst = IP_B1 : dst = IP_S 258 : : 259 +------+----+ : +------+----+ :+------+----+ 260 | data | IP | : | data | IP | :| data | IP | 261 +------+----+ : +------+----+ :+------+----+ 262 <--------------------- -: <-------------------- : <------------ 263 src = IP_S : src = IP_S : src = IP_S 264 dst = IP_C1 : dst = IP_C1 : dst = IP_C1 265 : : 267 Figure 6 269 In this figure, to the Client, IP address is allocated IP_C1, IP_C2, 270 and server IP address is IP_S. This case, IP_S is also allocate to 271 all servers and MSLB-F. And to the MSLB-B, IP_B1, IP_B2, IP_B3 is 272 allocated. These allocation is shown in upper part of Figure 6. 274 Lower part of Figure 6 shows packet transfered between client and 275 server. From Client to the Server, only destination address is 276 translate, MSLB-F translate from IP_S to IP_B1, and MSLB-B translate 277 from IP_B1 to IP_S. Then the destination address of packet which send 278 client and the destination address of packet which recieve server is 279 same address. That mean, transparency is remained. 281 Return packet, i.e., from server to the client is not translate, just 282 forwarded. 284 In the Internet, Client IP address and server IP address must Global 285 IP address, however, IP address of MSLB-B may private IP address. 287 +--------------------+----------+-------------------------+ 288 | Source IP address | net mask | destination IP address | 289 +--------------------+----------+-------------------------+ 290 | IP_C1 | | IP_B1 | 291 +--------------------+----------+-------------------------+ 292 | IP_C2 | | IP_B2 | 293 +--------------------+----------+-------------------------+ 294 | : | : | : | 295 | : | : | : | 296 | : | : | : | 297 +--------------------+----------+-------------------------+ 299 Figure 7 301 Figure 7 shows MSLB table. MSLB have this table and translate the 302 destination address using this table value. MSLB-F check source IP 303 address, and translate destination address with this table. 305 Using IPv4-IPv6 translation may possible, i.e., IPv4 packet 306 translated to IPv6, then translate to IPv4 or IPv6 packet translate 307 to IPv4, then translate IPv6 may possibleFigure 8 shows possible 308 combination of IPv4 and IPv6. These IPv4-IPv6 translation case will 309 be defined in future. 311 Client MSLB-F MSLB-B Server 312 : : 313 : : 314 (1) <-- IPv4 --> : <-- IPv4 --> : <-- IPv4 --> 315 : : 316 (2) <-- IPv6 --> : <-- IPv6 --> : <-- IPv6 --> 317 : : 318 (3) <-- IPv4 --> : <-- IPv6 --> : <-- IPv4 --> 319 : : 320 (4) <-- IPv6 --> : <-- IPv4 --> : <-- IPv6 --> 321 : : 323 Figure 8 325 5.2. encapsulation mode 327 This mode using encapsulation technique. 329 Figure Figure 9 shows packet processing with encapsulation mode. 331 +-------+ +------+ +------+ 332 | +---+MSLB-B+---+Server| 333 | | | IP_B1| | IP_S | 334 +-------+ +------+ | | +------+ +------+ 335 | | | | | | 336 +------+ | | | | | | +------+ +------+ 337 |Client|---+Network+---+MSLB-F|---+Network+---+MSLB-B+---+Server| 338 | IP_C | | | | | | | | IP_B2| | IP_S | 339 +------+ | | | IP_S | | | +------+ +------+ 340 | | | | | | 341 +-------+ +------+ | | +------+ +------+ 342 | +---+MSLB-B+---+Server| 343 | | | IP_B3| | IP_S | 344 +-------+ +------+ +------+ 345 : : 346 : : 347 +------+----+ : +------+----+----+ :+------+----+ 348 | data | IP | : | data | IP | IP | :| data | IP | 349 +------+----+ : +------+----+----+ :+------+----+ 350 ----------------------> : --------------------> : ------------> 351 src = IP_C : Inner header : src = IP_C 352 dst = IP_S : src = IP_C : dst = IP_S 353 : dst = IP_S : 354 : Outer header : 355 : src = IP_S : 356 : dst = IP_B1 : 357 : : 358 : : 359 : : 360 +------+----+ : +------+----+ :+------+----+ 361 | data | IP | : | data | IP | :| data | IP | 362 +------+----+ : +------+----+ :+------+----+ 363 <--------------------- -: <-------------------- : <------------ 364 src = IP_S : src = IP_S : src = IP_S 365 dst = IP_C : dst = IP_C : dst = IP_C 366 : : 368 Figure 9 370 In this figure, to the Client, IP address is allocated IP_C1, IP_C2, 371 and server IP address is IP_S. This case, IP_S is also allocate to 372 all servers and MSLB-F. And to the MSLB-B, IP_B1, IP_B2, IP_B3 is 373 allocated. These allocation is shown in upper part of Figure 6. 375 Lower part of Figure 6 shows packet transfered between client and 376 server. From Client to the Server, MSLB-F encapsulate original IP 377 packet and send to MSLB-B. MSLB-B decapsulate outer IP header, and 378 forwarad to the server. Inner IP packet does not change, that mean, 379 transparency is remained. 381 With encapsulation mode, packet size is increase, so fragmentation is 382 needed if encapsulated packet size exceed MTU or Path MTU. MSLB-F 383 MUST support tunnel MTU discovery [RFC1853]. Fragmentation and Path 384 MTU discovery [RFC1191] issue will describe in future. 386 Return packet, i.e., from server to the client is not encapsulate, 387 just forwarded. 389 In the Internet, Client IP address and server IP address must Global 390 IP address, however, IP address of MSLB-B may private IP address. 392 +--------------------+----------+-------------------------+ 393 | Source IP address | net mask | destination IP address | 394 +--------------------+----------+-------------------------+ 395 | IP_C1 | | IP_B1 | 396 +--------------------+----------+-------------------------+ 397 | IP_C2 | | IP_B2 | 398 +--------------------+----------+-------------------------+ 399 | : | : | : | 400 | : | : | : | 401 | : | : | : | 402 +--------------------+----------+-------------------------+ 404 Figure 10 406 Figure 10 shows MSLB table. MSLB have this table and encapsulate and 407 generate outer header with destination address using this table 408 value. MSLB-F check source IP address, and generate destination 409 address of outer header with this table. 411 Using IPv4 over IPv6 encapsulation or IPv6 over IPv4 encapsulation 412 may possible, i.e., IPv4 packet encapsulated to IPv6, then 413 decapsulate to IPv4 or IPv6 packet encapsulated to IPv4, then 414 deencapsulated IPv6 may possibleFigure 11 shows possible combination 415 of IPv4 and IPv6. These IPv4-IPv6 encapsulation case will be defined 416 in future. 418 Client MSLB-F MSLB-B Server 419 : : 420 : : 421 (1) <-- IPv4 --> : <-- IPv4 over IPv4 --> : <-- IPv4 --> 422 : : 423 (2) <-- IPv6 --> : <-- IPv6 over IPv6 --> : <-- IPv6 --> 424 : : 425 (3) <-- IPv4 --> : <-- IPv4 over IPv6 --> : <-- IPv4 --> 426 : : 427 (4) <-- IPv6 --> : <-- IPv6 over IPv4 --> : <-- IPv6 --> 428 : : 430 Figure 11 432 6. Ingress filtering environment 434 [RFC2827] describe ingress filtering for defending DoS attack which 435 employ IP source address spoofing. 437 Depend on the location of the MSLB-F and MSLB-B, it is possible that 438 packet from server to client is discarded by ingress filtering. In 439 such case, encapsulating the packet from server to client might 440 resolve. Figure 12 shows such solution. 442 +-------+ +------+ +------+ 443 | +---+MSLB-B+---+Server| 444 +------+ | | | IP_B1| | IP_S | 445 |Client| +-------+ +------+ | | +------+ +------+ 446 | IP_C1+---+ | | | | | 447 +------+ | | | | | | +------+ +------+ 448 |Network| |MSLB-F|---+Network+---+MSLB-B+---+Server| 449 | +---+ | | | | IP_B2| | IP_S | 450 +------+ | | | IP_S | | | +------+ +------+ 451 |Client+---+ | | | | | 452 | IP_C2| +-------+ +------+ | | +------+ +------+ 453 +------+ | +---+MSLB-B+---+Server| 454 | | | IP_B3| | IP_S | 455 +-------+ +------+ +------+ 457 : : 458 +------+----+ : +------+----+----+ :+------+----+ 459 | data | IP | : | data | IP | IP | :| data | IP | 460 +------+----+ : +------+----+----+ :+------+----+ 461 <--------------------- -: <-------------------- : <------------ 462 src = IP_S : Inner header : src = IP_S 463 dst = IP_C : src = IP_S : dst = IP_C 464 : dst = IP_C : 465 : Outer header : 466 : src = IP_B1 467 : dst = IP_TBD 469 Figure 12 471 7. Characteristic 473 MSLB has following characteristics. 475 o Layer 3 Load balancer 477 o Support NAT unfriendly application such as FTP 479 o work with any application layer protocol (maybe) 481 o work with encription (IPsec ESP, SSL/TLS) 483 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. References 501 11.1. Normative References 503 [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, 504 DOI 10.17487/RFC1191, November 1990, 505 . 507 [RFC1546] Partridge, C., Mendez, T., and W. Milliken, "Host 508 Anycasting Service", RFC 1546, DOI 10.17487/RFC1546, 509 November 1993, . 511 [RFC1853] Simpson, W., "IP in IP Tunneling", RFC 1853, DOI 10.17487/ 512 RFC1853, October 1995, 513 . 515 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 516 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 517 RFC2119, March 1997, 518 . 520 [RFC2775] Carpenter, B., "Internet Transparency", RFC 2775, 521 DOI 10.17487/RFC2775, February 2000, 522 . 524 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 525 Defeating Denial of Service Attacks which employ IP Source 526 Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827, 527 May 2000, . 529 [RFC2993] Hain, T., "Architectural Implications of NAT", RFC 2993, 530 DOI 10.17487/RFC2993, November 2000, 531 . 533 11.2. Informative References 535 Author's Address 537 Naoki Matsuhira 538 Fujitsu Limited 539 17-25, Shinkamata 1-chome, Ota-ku 540 Tokyo, 144-8588 541 Japan 543 Phone: +81-3-3735-1111 544 Fax: 545 Email: matsuhira@fujitsu.com