Network working group X. Wang Internet Draft Huawei Category: Informational Y. Wang Expires: August 2010 CNNIC C. Byrne T-Mobile USA D. Zhang Huawei February 22, 2010 Some Considerations on the Load-Balancer for NAT64 draft-wang-behave-nat64-load-balancer-01 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 August 22, 2010 [Page 1] Internet-Draft Some Considerations on the February 2010 Load-Balancer for NAT64 Abstract [STANDBY] has discussed how to achieve load-balancing among a group of NAT64 devices, however, it doesn't mention the mechanism to achieve load-balancing with load-balancers, e.g., how to assign different prefix64s to different hosts. 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 August 22, 2010 [Page 2] Internet-Draft Some Considerations on the February 2010 Load-Balancer for NAT64 1. Introduction NAT64 gateway [NAT64] is an equipment for data translation between IP v4 and v6 address families. With the development of the network, the data transmission volume is increasing rapidly. In order to facilitate the NAT64 system scalability and resilience, load- balancing is one of the most important requirements for NAT64 systems. [STANDBY] has discussed the load-balancing mechanism for NAT64, however, the load-balancer mechanism has not been defined explicitly. This memo analyzes and summarizes the different prefix selection policies and load-balancer approaches, which are used together with the corresponding 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 The load-balancer enables an IPv6 client to be assigned to a certain NAT64 box by distributing a certain prefix64 that is associated with a functioning and available NAT64 system. E.g., there are two or more NAT64 systems (NAT64-A and NAT64-B, where NAT64-A may actually be 2 devices configured for local 1+1 redundancy) providing protocol translation between an IPv6 network and the IPv4 Internet, and prefix64-A and prefix64-B corresponding to NAT64-A and NAT64-B separately. An IPv6 client in the IPv6 network wants to initiate a communication with an IPv4 server in the IPv4 Internet. If the load- balancer allocates prefix64-A for the session, the IPv6 client will choose NAT64-A to communicate with the IPv4 server, and if prefix64- B, will choose NAT64-B. In order to achieve load balancing for a set of NAT64 boxes, a load- balancer can allocate prefix64s for the IPv4 server based on prefix Wang Expires August 22, 2010 [Page 3] Internet-Draft Some Considerations on the February 2010 Load-Balancer for NAT64 selection policies, thus the load can be distributed on all available NAT64 systems within a given autonomous system's defined scope. This section provides some prefix selection policies, three static and one dynamic. These policies are not specific to any load- balancer mechanism. 3.1. Source-Based Prefix Selection Policy A source-based prefix selection policy allows a load-balancer to choose prefix64s according to the IP address of the requesting client. In the above example, one of the prefix selection policies is to choose prefix64s according to the parity of the IP address of the requesting client, and the load-balancer can choose prefix64-A if the IPv6 address of the requesting client is odd, and prefix64-B if even. 3.1.1. Pros 1. Simple and has enough entropy to ensure reasonable load balancing across 2 systems. 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. In the above example, load-balancer can choose prefix64-A if the IPv4 address of the IPv4 server queried by the requesting client is odd, and prefix64-B if even. 3.2.1. Pros The pros of this policy are left for the future exploration. Wang Expires August 22, 2010 [Page 4] Internet-Draft Some Considerations on the February 2010 Load-Balancer for NAT64 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 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 Wang Expires August 22, 2010 [Page 5] Internet-Draft Some Considerations on the February 2010 Load-Balancer for NAT64 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 implementors. 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 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. Wang Expires August 22, 2010 [Page 6] Internet-Draft Some Considerations on the February 2010 Load-Balancer for NAT64 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 communicate with, edge router can't use destination-based prefix selection policy. Wang Expires August 22, 2010 [Page 7] Internet-Draft Some Considerations on the February 2010 Load-Balancer for NAT64 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 August 22, 2010 [Page 8] Internet-Draft Some Considerations on the February 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 August 22, 2010 [Page 9] Internet-Draft Some Considerations on the February 2010 Load-Balancer for NAT64 Authors' Addresses 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 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 Dacheng Zhang Huawei Technologies Co.,Ltd KuiKe Building, No.9 Xinxi Rd., Hai-Dian District Beijing, 100085 P.R. China Email: zhangdacheng@huawei.com Wang Expires August 22, 2010 [Page 10]