idnits 2.17.1 draft-wang-behave-nat64-load-balancer-02.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 : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 4 instances of too long lines in the document, the longest one being 1 character in excess of 72. ** The abstract seems to contain references ([STANDBY]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 354 has weird spacing: '...amework for ...' == Line 376 has weird spacing: '...00(work in p...' == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (August 25, 2010) is 4965 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC2119' is mentioned on line 63, but not defined == Outdated reference: A later version (-06) exists of draft-xu-behave-stateful-nat-standby-01 == Outdated reference: A later version (-12) exists of draft-ietf-behave-v6v4-xlate-stateful-07 == Outdated reference: A later version (-11) exists of draft-ietf-behave-dns64-05 == Outdated reference: A later version (-10) exists of draft-ietf-behave-address-format-00 Summary: 4 errors (**), 0 flaws (~~), 9 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network working group D. Zhang 2 Internet Draft Huawei 3 Category: Informational Y. Wang 4 Expires: February 2011 CNNIC 5 C. Byrne 6 T-Mobile USA 7 X. Wang 8 Huawei 9 August 25, 2010 11 Some Considerations on the Load-Balancer for NAT64 12 draft-wang-behave-nat64-load-balancer-02 14 Status of this Memo 16 This Internet-Draft is submitted to IETF in full conformance with 17 the provisions of BCP 78 and BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six 25 months and may be updated, replaced, or obsoleted by other documents 26 at any time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on August 15, 2009. 37 Copyright Notice 39 Copyright (c) 2009 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with 47 respect to this document. 49 Load-Balancer for NAT64 51 Abstract 53 [STANDBY] has discussed how to achieve load-balancing among a group 54 of NAT64 devices. However, it doesn't explore the issues with 55 achieving load-balancing with load-balancers. In this memo, we 56 propose our investigation on this topic. 58 Conventions used in this document 60 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 61 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 62 document are to be interpreted as described in RFC-2119 [RFC2119]. 64 Table of Contents 66 1. Introduction...................................................3 67 2. Terminology....................................................3 68 3. Prefix Selection Policy........................................3 69 3.1. Source-Based Prefix Selection Policy......................4 70 3.2. Destination-Based Prefix Selection Policy.................4 71 3.3. Round-Robin Prefix Selection Policy.......................5 72 3.4. Dynamic Prefix Selection Policy...........................5 73 4. Load-balancer Selection........................................6 74 4.1. DNS64 as Load-balancer....................................6 75 4.2. Prefix64 Assigner as Load-balancer........................6 76 4.2.1. DNS Server as Load-balancer..........................7 77 4.2.2. DHCPv6 Server as Load-balancer.......................7 78 4.2.3. Default Gateway as Load-balancer.....................7 79 4.2.4. IPv6 Client as Load-balancer.........................8 80 5. Change Log.....................................................8 81 5.1.1. Changes between -00 and -01..........................8 82 6. References.....................................................8 83 6.1. Normative References......................................8 84 6.2. Informative References....................................8 85 Authors' Addresses...............................................10 86 Load-Balancer for NAT64 88 1. Introduction 90 NAT64 gateways [NAT64] are facilities for data translation between 91 IP v4 and v6 address namespaces. With the development of the network, 92 the data transmission volume is increasing rapidly. It is reasonable 93 to expect that the overheads imposed on a NAT64 gateway system can 94 be very heavy in many circumstances. Therefore, in order to endow a 95 good scalability with NAT64 systems, the issues with the designing 96 of load-balancing mechanisms need to be carefully investigated. In 97 [STANDBY], some issues with load-balancing mechanism for NAT64 is 98 discussed, but the issues with load-balancer mechanisms have not 99 been not been well explored yet. This memo proposes several 100 candidate load-balancer approaches and compared several different 101 prefix selection policies. In practice, the load-balancer approaches 102 can work cooperatively with the address synthesis approaches defined 103 in [DNS64] and [Learn_Prefix]. 105 2. Terminology 107 This memo makes use of the terms defined in [NAT64] and [DNS64]. 108 Below are provided terms specific to this document: 110 Prefix64: an IPv6 prefix used for synthesizing IPv6 addresses for 111 the IPv4 hosts. See [Format] for more details. 113 NAT64 System: one NAT64 device or two NAT64 devices in a 1+1 114 redundancy configuration. At NAT64 system is responsible for the 115 translation of all packets destine to a given Prefix64. There is a 116 tight coupling of a NAT64 device, Prefix64, and a set of public IPv4 117 addresses. 119 3. Prefix Selection Policy 121 A load-balancer is a facility which is able to select a NAT64 122 gateway from a group of gateway based on pre-specified policies and 123 assign the gateway to provide services for an IPv6 client. Typically, 124 the load-balancer achieves this by informing the client of an IPv6 125 address which the client can use to communicate with an IPv4 target. 126 Particularly, the IPv6 address consists of a prefix64 associated 127 with the selected gateway. 129 Assume there are two NAT64 gateways (NAT64-A and NAT64-B) in a NAT64 130 system which provides protocol translation services between an IPv6 131 network and the IPv4 Internet. The prefix64s of NAT64-A and NAT64-B 132 are noted as prefix64-A and prefix64-B respectively. In the IPv6 133 Load-Balancer for NAT64 135 network, an IPv6 client needs to contact the load-balancer before it 136 attempts to communicate with an IPv4 server in the IPv4 Internet. 137 After receiving a request from a client, the load-balancer responds 138 with an IPv6 address. If the prefix of the IPv6 address is prefix64- 139 A, it is indicated that the client will the IPv6 address to 140 communicate with the IPv4 server under the assistance of NAT64-A. 141 Similarly, if the prefix of the IPv6 address is prefix64-B, it is 142 indicated that the client will communicate with the IPv4 server 143 under the assistance of NAT64-B. In this way, the payloads can be 144 distributed on different NAT64 gateways according to certain 145 policies. 147 In the remainder of this section, four types of prefix selection 148 policies are introduced. Three of them are static, and one is 149 dynamic. 151 3.1. Source-Based Prefix Selection Policy 153 A source-based prefix selection policy allows a load-balancer to 154 select prefix64s according to the IPv6 addresses of its clients. For 155 instance, when using a source-based prefix selection policy, the 156 load-balancer in the above example can allocate an IPv6 address with 157 prefix64-A for the IPv4 server if the IPv6 address of the client is 158 odd, and prefix64-B otherwise. 160 3.1.1. Pros 162 1. It is simple and has enough entropy to ensure reasonable load 163 balancing across different NAT64 gateways. 165 2. The users are consistently assigned to the same NAT64 for every 166 transaction. This is important because some application identify 167 a unique user across multiple transactions using the source IP 168 address, examples include FTP and SSL VPNs. 170 3.1.2. Cons 172 The cons of this policy are left for the future exploration. 174 3.2. Destination-Based Prefix Selection Policy 176 A destination-based prefix selection policy is that a load-balancer 177 chooses prefix64s according to the IP address of the IPv4 server. 178 For instance, when using a destination-Based Prefix Selection Policy, 179 the load-balancer in the above example can allocate an IPv6 address 180 Load-Balancer for NAT64 182 with prefix64-A for the IPv4 server if the IPv4 address of the 183 server is odd, and prefix64-B otherwise. 185 3.2.1. Pros 187 The pros of this policy are left for the future exploration. 189 3.2.2. Cons 191 1. A given user will be represented by multiple public IPv4 192 addresses since a source will go to multiple NAT64 systems. This 193 is important because some application identify a unique user 194 across multiple transactions using the source IP address, 195 examples include FTP and SSL VPNs. 197 2. Since there are more viewers than content, there is not enough 198 entropy to ensure good load balancing. The NAT64 system that 199 services a major site like Google or Facebook will take too much 200 traffic. Though we can define some strategies to make major 201 sites evenly assigned to different NAT64s, e.g., Google to 202 NAT64-A, Facebook to NAT64-B, but that seems to be static and 203 manual process. 205 3.3. Round-Robin Prefix Selection Policy 207 A round-robin prefix selection policy allows a load-balancer to 208 choose prefix64s according to the arriving sequence of the 209 requesting session. In the above example, load-balancer can choose 210 prefix64-A to the first arriving requesting session, prefix64-B to 211 the second, prefix64-A to the third, prefix64-B to the fourth, and 212 so on. 214 3.3.1. Pros 216 The pros of this policy are left for the future exploration. 218 3.3.2. Cons 220 1 Requires DNS64 or DHCP to have a state table to keep track of 221 assignments 223 3.4. Dynamic Prefix Selection Policy 225 The above three policies are all static prefix selection policies, 226 though they could pre-evaluate the capabilities of NAT64 boxes based 227 Load-Balancer for NAT64 229 on some criterions and allocate the prefix64s according to the 230 capabilities of their NAT64 boxes, whereas once the evaluation is 231 finished, these policies are fixed and can't reflect NAT64s' timely 232 load changes. If we intend to enable load-balancer to change the 233 prefix64s according to NAT64s' real-time load changes, a dynamic 234 prefix selection policy is necessary. A DNS64 system or DHCPv6 may 235 SNMP poll the NAT64 for key performance indicators such as CPU 236 utilization, free memory, concurrent sessions, and sessions per 237 second. Based on the relative loading of the systems, the load 238 balancing mechanism can distribute new load proportionally. This 239 method perhaps brings a certain amount of system complexities, so 240 some simplified performance indicators can be considered. This is 241 the choice of the implementers. 243 The pros and cons of this policy are left for the future exploration. 245 4. Load-balancer Selection 247 A load-balancer can be a DNS64, a DNS server, a DHCP server, an edge 248 router, or the IPv6 host self. There are some special considerations 249 with the different load-balancers. 251 4.1. DNS64 as Load-balancer 253 DNS64 is a mechanism for synthesizing AAAA resource records (RRs) 254 from A RRs. Together with NAT64 translator; these two mechanisms 255 enable an IPv6-only client to initiate communications to an IPv4- 256 only server using the FQDN of the server. DNS64 synthesizes an AAAA 257 RR from an A RR containing a real IPv4 address of the responder and 258 a prefix64. 260 In the scenario of an IPv6 client in an IPv6 network wants to 261 initiate a communication with an IPv4 server in the IPv4 Internet, 262 for load balancing DNS64 decides which prefix64 to be used in the 263 synthesized response based on one of the prefix selection policies 264 defined in the section 3. With the synthesized IPv6 address, the 265 IPv6 client will choose the NAT64 corresponding to the prefix64 of 266 the IPv6 address is synthesized with to communicate with the IPv4 267 server. 269 4.2. Prefix64 Assigner as Load-balancer 271 [Learn_Prefix] has provided some mechanisms for the hosts in the 272 IPv6 network to obtain the prefix64 of their NAT64, with the 273 prefix64 the hosts could synthesize an appropriate IPv6 address that 274 Load-Balancer for NAT64 276 will be routed to the translator for the translator to process. In 277 the context of load balancing for NAT64 boxes, these mechanisms have 278 some special consideration. 280 4.2.1. DNS Server as Load-balancer 282 [Learn_Prefix] has defined a NAPTR RR to represent NAT64's prefix64. 283 To achieve load balancing for NAT64 boxes, there is a requirement to 284 add multiple NAPTR RRs to zone file corresponding to each prefix64. 285 Upon receiving a NAPTR query, DNS server responses to the requestor 286 one of these NAPTR RRs based on source-based or round-robin or 287 dynamic prefix selection policy. Because having no knowledge of the 288 IP address of the queried IPv4 server, destination-based prefix 289 selection policy is not suitable in this case. 291 4.2.2. DHCPv6 Server as Load-balancer 293 Another mechanism for a host to learn the prefix64 of its NAT64 294 described in [Learn_Prefix] is to make DHCP server to allocate 295 prefix64 to the hosts. The prefix selection policy can be source- 296 based, round-robin, or dynamic. Because having no knowledge of the 297 IP address of the IPv4 server which its client wants to communicate 298 with, DHCPv6 server can't use destination-based prefix selection 299 policy. 301 Alternatively, the DHCPv6 server can allocate a DNS64 server as part 302 of the standard DHCPv6 host configuration process where the DHCPv6 303 server provides and DNS server to the client. The DNS64 server in 304 this instance provides synthesized AAAA records using a unique 305 prefix64 serviced by a unique NAT64 system. In this way, the DHCPv6 306 assigns one of many available DNS64 and NAT64 combinations which 307 serve synthesized AAAA to the host. So, the DHCPv6 pushes one of 308 many DNS64 servers to the host, and the DNS64 server drives traffic 309 to one of many NAT64 systems. 311 4.2.3. Default Gateway as Load-balancer 313 [Learn_Prefix] also uses Router Advertisement (RA) messages to 314 transfer the prefix64 to the IPv6 hosts. If the edge router is 315 attached to only one multicast link, no prefix selection policy 316 defined in the section 3 can be used. If the edge router is attached 317 to multiple multicast links, the prefix selection policy can be 318 source-based or round-robin or dynamic. Due to have no knowledge of 319 the IP address of the IPv4 server which its host wants to 320 Load-Balancer for NAT64 322 communicate with, edge router can't use destination-based prefix 323 selection policy. 325 4.2.4. IPv6 Client as Load-balancer 327 Multiple prefix64s are learnt through the approaches defined in 328 [learn-prefix], it's up to the IPv6 client to determine which prefix 329 is used. The prefix selection policy can be destination-based, 330 source-based (only one prefix64 is used) or round-robin or dynamic. 332 5. Change Log 334 5.1.1. Changes between -00 and -01 336 There were several changes made between the -00 and -01 versions of 337 this draft: 339 o Added Cameron Byrne and Dacheng Zhang as co-authors. 341 o Added some discussions about pros and cons at section 3.1. 343 o Added a new mechanism at section 4.2.2. 345 o Add minor mathematical corrections. 347 6. References 349 6.1. Normative References 351 6.2. Informative References 353 [STANDBY] Xiaohu Xu, Mohamed Boucadair, " Redundancy and Load 354 Balancing Framework for Stateful Network Address 355 Translators (NAT)", draft-xu-behave-stateful-nat- 356 standby-01(work in progress), September, 2009. 358 [NAT64] Bagnulo, M., Matthews, P., and I. Beijnum, " NAT64: 359 Network Address and Protocol Translation from IPv6 360 Clients to IPv4 Servers ", draft-ietf-behave-v6v4- 361 xlate-stateful-07(work in progress), December, 2009. 363 [DNS64] M. Bagnulo, A. Sullivan, P. Matthews, I. van Beijnum, 364 "DNS64: DNS extensions for Network Address Translation 365 from IPv6 Clients to IPv4 Servers", draft-ietf-behave- 366 dns64-05(work in progress), December, 2009. 368 Load-Balancer for NAT64 370 [Learn_Prefix] D. Wing, "Learning the IPv6 Prefix of a Network's 371 IPv6/IPv4 Translator", draft-wing-behave-learn-prefix- 372 04(work in progress), October, 2009. 374 [Format] Huitema,C., Bao, C., Bagnulo, M., Boucadair, M., Li, 375 X., "Framework for IPv4/IPv6 Translation", draft-ietf- 376 behave-address-format-00(work in progress), August, 377 2009. 379 Load-Balancer for NAT64 381 Authors' Addresses 383 Dacheng Zhang 384 Huawei Technologies Co.,Ltd 385 KuiKe Building, No.9 Xinxi Rd., 386 Hai-Dian District 387 Beijing, 100085 388 P.R. China 390 Email: zhangdacheng@huawei.com 392 Yan Wang 393 CNNIC 394 No.4 South 4th Street, Zhongguancun 395 Beijing, 100190 396 P. R. China 397 Phone: +86 10 58813315 399 Email: wangyan-lab@cnnic.cn 401 Cameron Byrne 402 T-Mobile USA 403 3617 131st Ave SE 404 Bellevue, WA 98006 406 Email: cameron.byrne@t-mobile.com 408 Xuewei Wang 409 Huawei Technologies Co.,Ltd 410 KuiKe Building, No.9 Xinxi Rd., 411 Hai-Dian District 412 Beijing, 100085 413 P.R. China 414 Phone: +86 10 82836075 416 Email: wangxuewei@huawei.com