Network working group D. Zhang Internet Draft Huawei Category: Informational Y. Wang Expires: February 2011 CNNIC C. Byrne T-Mobile USA X. Wang Huawei August 25, 2010 Some Considerations on the Load-Balancer for NAT64 draft-wang-behave-nat64-load-balancer-02 Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on August 15, 2009. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Wang Expires February 25, 2011 [Page 1] Internet-Draft Some Considerations on the August 2010 Load-Balancer for NAT64 Abstract [STANDBY] has discussed how to achieve load-balancing among a group of NAT64 devices. However, it doesn't explore the issues with achieving load-balancing with load-balancers. In this memo, we propose our investigation on this topic. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [RFC2119]. Table of Contents 1. Introduction...................................................3 2. Terminology....................................................3 3. Prefix Selection Policy........................................3 3.1. Source-Based Prefix Selection Policy......................4 3.2. Destination-Based Prefix Selection Policy.................4 3.3. Round-Robin Prefix Selection Policy.......................5 3.4. Dynamic Prefix Selection Policy...........................5 4. Load-balancer Selection........................................6 4.1. DNS64 as Load-balancer....................................6 4.2. Prefix64 Assigner as Load-balancer........................6 4.2.1. DNS Server as Load-balancer..........................7 4.2.2. DHCPv6 Server as Load-balancer.......................7 4.2.3. Default Gateway as Load-balancer.....................7 4.2.4. IPv6 Client as Load-balancer.........................8 5. Change Log.....................................................8 5.1.1. Changes between -00 and -01..........................8 6. References.....................................................8 6.1. Normative References......................................8 6.2. Informative References....................................8 Authors' Addresses...............................................10 Wang Expires February 25, 2011 [Page 2] Internet-Draft Some Considerations on the August 2010 Load-Balancer for NAT64 1. Introduction NAT64 gateways [NAT64] are facilities for data translation between IP v4 and v6 address namespaces. With the development of the network, the data transmission volume is increasing rapidly. It is reasonable to expect that the overheads imposed on a NAT64 gateway system can be very heavy in many circumstances. Therefore, in order to endow a good scalability with NAT64 systems, the issues with the designing of load-balancing mechanisms need to be carefully investigated. In [STANDBY], some issues with load-balancing mechanism for NAT64 is discussed, but the issues with load-balancer mechanisms have not been not been well explored yet. This memo proposes several candidate load-balancer approaches and compared several different prefix selection policies. In practice, the load-balancer approaches can work cooperatively with the address synthesis approaches defined in [DNS64] and [Learn_Prefix]. 2. Terminology This memo makes use of the terms defined in [NAT64] and [DNS64]. Below are provided terms specific to this document: Prefix64: an IPv6 prefix used for synthesizing IPv6 addresses for the IPv4 hosts. See [Format] for more details. NAT64 System: one NAT64 device or two NAT64 devices in a 1+1 redundancy configuration. At NAT64 system is responsible for the translation of all packets destine to a given Prefix64. There is a tight coupling of a NAT64 device, Prefix64, and a set of public IPv4 addresses. 3. Prefix Selection Policy A load-balancer is a facility which is able to select a NAT64 gateway from a group of gateway based on pre-specified policies and assign the gateway to provide services for an IPv6 client. Typically, the load-balancer achieves this by informing the client of an IPv6 address which the client can use to communicate with an IPv4 target. Particularly, the IPv6 address consists of a prefix64 associated with the selected gateway. Assume there are two NAT64 gateways (NAT64-A and NAT64-B) in a NAT64 system which provides protocol translation services between an IPv6 network and the IPv4 Internet. The prefix64s of NAT64-A and NAT64-B are noted as prefix64-A and prefix64-B respectively. In the IPv6 Wang Expires February 25, 2011 [Page 3] Internet-Draft Some Considerations on the August 2010 Load-Balancer for NAT64 network, an IPv6 client needs to contact the load-balancer before it attempts to communicate with an IPv4 server in the IPv4 Internet. After receiving a request from a client, the load-balancer responds with an IPv6 address. If the prefix of the IPv6 address is prefix64- A, it is indicated that the client will the IPv6 address to communicate with the IPv4 server under the assistance of NAT64-A. Similarly, if the prefix of the IPv6 address is prefix64-B, it is indicated that the client will communicate with the IPv4 server under the assistance of NAT64-B. In this way, the payloads can be distributed on different NAT64 gateways according to certain policies. In the remainder of this section, four types of prefix selection policies are introduced. Three of them are static, and one is dynamic. 3.1. Source-Based Prefix Selection Policy A source-based prefix selection policy allows a load-balancer to select prefix64s according to the IPv6 addresses of its clients. For instance, when using a source-based prefix selection policy, the load-balancer in the above example can allocate an IPv6 address with prefix64-A for the IPv4 server if the IPv6 address of the client is odd, and prefix64-B otherwise. 3.1.1. Pros 1. It is simple and has enough entropy to ensure reasonable load balancing across different NAT64 gateways. 2. The users are consistently assigned to the same NAT64 for every transaction. This is important because some application identify a unique user across multiple transactions using the source IP address, examples include FTP and SSL VPNs. 3.1.2. Cons The cons of this policy are left for the future exploration. 3.2. Destination-Based Prefix Selection Policy A destination-based prefix selection policy is that a load-balancer chooses prefix64s according to the IP address of the IPv4 server. For instance, when using a destination-Based Prefix Selection Policy, the load-balancer in the above example can allocate an IPv6 address Wang Expires February 25, 2011 [Page 4] Internet-Draft Some Considerations on the August 2010 Load-Balancer for NAT64 with prefix64-A for the IPv4 server if the IPv4 address of the server is odd, and prefix64-B otherwise. 3.2.1. Pros The pros of this policy are left for the future exploration. 3.2.2. Cons 1. A given user will be represented by multiple public IPv4 addresses since a source will go to multiple NAT64 systems. This is important because some application identify a unique user across multiple transactions using the source IP address, examples include FTP and SSL VPNs. 2. Since there are more viewers than content, there is not enough entropy to ensure good load balancing. The NAT64 system that services a major site like Google or Facebook will take too much traffic. Though we can define some strategies to make major sites evenly assigned to different NAT64s, e.g., Google to NAT64-A, Facebook to NAT64-B, but that seems to be static and manual process. 3.3. Round-Robin Prefix Selection Policy A round-robin prefix selection policy allows a load-balancer to choose prefix64s according to the arriving sequence of the requesting session. In the above example, load-balancer can choose prefix64-A to the first arriving requesting session, prefix64-B to the second, prefix64-A to the third, prefix64-B to the fourth, and so on. 3.3.1. Pros The pros of this policy are left for the future exploration. 3.3.2. Cons 1 Requires DNS64 or DHCP to have a state table to keep track of assignments 3.4. Dynamic Prefix Selection Policy The above three policies are all static prefix selection policies, though they could pre-evaluate the capabilities of NAT64 boxes based Wang Expires February 25, 2011 [Page 5] Internet-Draft Some Considerations on the August 2010 Load-Balancer for NAT64 on some criterions and allocate the prefix64s according to the capabilities of their NAT64 boxes, whereas once the evaluation is finished, these policies are fixed and can't reflect NAT64s' timely load changes. If we intend to enable load-balancer to change the prefix64s according to NAT64s' real-time load changes, a dynamic prefix selection policy is necessary. A DNS64 system or DHCPv6 may SNMP poll the NAT64 for key performance indicators such as CPU utilization, free memory, concurrent sessions, and sessions per second. Based on the relative loading of the systems, the load balancing mechanism can distribute new load proportionally. This method perhaps brings a certain amount of system complexities, so some simplified performance indicators can be considered. This is the choice of the implementers. The pros and cons of this policy are left for the future exploration. 4. Load-balancer Selection A load-balancer can be a DNS64, a DNS server, a DHCP server, an edge router, or the IPv6 host self. There are some special considerations with the different load-balancers. 4.1. DNS64 as Load-balancer DNS64 is a mechanism for synthesizing AAAA resource records (RRs) from A RRs. Together with NAT64 translator; these two mechanisms enable an IPv6-only client to initiate communications to an IPv4- only server using the FQDN of the server. DNS64 synthesizes an AAAA RR from an A RR containing a real IPv4 address of the responder and a prefix64. In the scenario of an IPv6 client in an IPv6 network wants to initiate a communication with an IPv4 server in the IPv4 Internet, for load balancing DNS64 decides which prefix64 to be used in the synthesized response based on one of the prefix selection policies defined in the section 3. With the synthesized IPv6 address, the IPv6 client will choose the NAT64 corresponding to the prefix64 of the IPv6 address is synthesized with to communicate with the IPv4 server. 4.2. Prefix64 Assigner as Load-balancer [Learn_Prefix] has provided some mechanisms for the hosts in the IPv6 network to obtain the prefix64 of their NAT64, with the prefix64 the hosts could synthesize an appropriate IPv6 address that Wang Expires February 25, 2011 [Page 6] Internet-Draft Some Considerations on the August 2010 Load-Balancer for NAT64 will be routed to the translator for the translator to process. In the context of load balancing for NAT64 boxes, these mechanisms have some special consideration. 4.2.1. DNS Server as Load-balancer [Learn_Prefix] has defined a NAPTR RR to represent NAT64's prefix64. To achieve load balancing for NAT64 boxes, there is a requirement to add multiple NAPTR RRs to zone file corresponding to each prefix64. Upon receiving a NAPTR query, DNS server responses to the requestor one of these NAPTR RRs based on source-based or round-robin or dynamic prefix selection policy. Because having no knowledge of the IP address of the queried IPv4 server, destination-based prefix selection policy is not suitable in this case. 4.2.2. DHCPv6 Server as Load-balancer Another mechanism for a host to learn the prefix64 of its NAT64 described in [Learn_Prefix] is to make DHCP server to allocate prefix64 to the hosts. The prefix selection policy can be source- based, round-robin, or dynamic. Because having no knowledge of the IP address of the IPv4 server which its client wants to communicate with, DHCPv6 server can't use destination-based prefix selection policy. Alternatively, the DHCPv6 server can allocate a DNS64 server as part of the standard DHCPv6 host configuration process where the DHCPv6 server provides and DNS server to the client. The DNS64 server in this instance provides synthesized AAAA records using a unique prefix64 serviced by a unique NAT64 system. In this way, the DHCPv6 assigns one of many available DNS64 and NAT64 combinations which serve synthesized AAAA to the host. So, the DHCPv6 pushes one of many DNS64 servers to the host, and the DNS64 server drives traffic to one of many NAT64 systems. 4.2.3. Default Gateway as Load-balancer [Learn_Prefix] also uses Router Advertisement (RA) messages to transfer the prefix64 to the IPv6 hosts. If the edge router is attached to only one multicast link, no prefix selection policy defined in the section 3 can be used. If the edge router is attached to multiple multicast links, the prefix selection policy can be source-based or round-robin or dynamic. Due to have no knowledge of the IP address of the IPv4 server which its host wants to Wang Expires February 25, 2011 [Page 7] Internet-Draft Some Considerations on the August 2010 Load-Balancer for NAT64 communicate with, edge router can't use destination-based prefix selection policy. 4.2.4. IPv6 Client as Load-balancer Multiple prefix64s are learnt through the approaches defined in [learn-prefix], it's up to the IPv6 client to determine which prefix is used. The prefix selection policy can be destination-based, source-based (only one prefix64 is used) or round-robin or dynamic. 5. Change Log 5.1.1. Changes between -00 and -01 There were several changes made between the -00 and -01 versions of this draft: o Added Cameron Byrne and Dacheng Zhang as co-authors. o Added some discussions about pros and cons at section 3.1. o Added a new mechanism at section 4.2.2. o Add minor mathematical corrections. 6. References 6.1. Normative References 6.2. Informative References [STANDBY] Xiaohu Xu, Mohamed Boucadair, " Redundancy and Load Balancing Framework for Stateful Network Address Translators (NAT)", draft-xu-behave-stateful-nat- standby-01(work in progress), September, 2009. [NAT64] Bagnulo, M., Matthews, P., and I. Beijnum, " NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers ", draft-ietf-behave-v6v4- xlate-stateful-07(work in progress), December, 2009. [DNS64] M. Bagnulo, A. Sullivan, P. Matthews, I. van Beijnum, "DNS64: DNS extensions for Network Address Translation from IPv6 Clients to IPv4 Servers", draft-ietf-behave- dns64-05(work in progress), December, 2009. Wang Expires February 25, 2011 [Page 8] Internet-Draft Some Considerations on the August 2010 Load-Balancer for NAT64 [Learn_Prefix] D. Wing, "Learning the IPv6 Prefix of a Network's IPv6/IPv4 Translator", draft-wing-behave-learn-prefix- 04(work in progress), October, 2009. [Format] Huitema,C., Bao, C., Bagnulo, M., Boucadair, M., Li, X., "Framework for IPv4/IPv6 Translation", draft-ietf- behave-address-format-00(work in progress), August, 2009. Wang Expires February 25, 2011 [Page 9] Internet-Draft Some Considerations on the August 2010 Load-Balancer for NAT64 Authors' Addresses Dacheng Zhang Huawei Technologies Co.,Ltd KuiKe Building, No.9 Xinxi Rd., Hai-Dian District Beijing, 100085 P.R. China Email: zhangdacheng@huawei.com Yan Wang CNNIC No.4 South 4th Street, Zhongguancun Beijing, 100190 P. R. China Phone: +86 10 58813315 Email: wangyan-lab@cnnic.cn Cameron Byrne T-Mobile USA 3617 131st Ave SE Bellevue, WA 98006 Email: cameron.byrne@t-mobile.com Xuewei Wang Huawei Technologies Co.,Ltd KuiKe Building, No.9 Xinxi Rd., Hai-Dian District Beijing, 100085 P.R. China Phone: +86 10 82836075 Email: wangxuewei@huawei.com Wang Expires February 25, 2011 [Page 10]