Network working group X. Wang Internet Draft Huawei Category: Informational Y. Wang Expires: June 2010 CNNIC December 31, 2009 Some Considerations on the Load-Balancer for NAT64 draft-wang-behave-nat64-load-balancer-00 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 in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Wang Expires June 31, 2010 [Page 1] Internet-Draft Some Considerations on the December 2009 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 for load-balancer, 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...................................................2 2. Terminology....................................................3 3. Prefix Selecting Policy........................................3 3.1. Source-Based Prefix Selecting Policy......................3 3.2. Destination-Based Prefix Selecting Policy.................4 3.3. Round-Robin Prefix Selecting Policy.......................4 3.4. Dynamic Prefix Selecting Policy...........................4 4. Load-balancer Selection........................................4 4.1. DNS64 as Load-balancer....................................5 4.2. Prefix64 Assigner as Load-balancer........................5 4.2.1. DNS Server as Load-balancer..........................5 4.2.2. DHCP Server as Load-balancer.........................5 4.2.3. Default Gateway as Load-balancer.....................6 4.2.4. IPv6 Client as Load-balancer.........................6 5. References.....................................................6 5.1. Normative References......................................6 5.2. Informative References....................................6 Authors' Addresses................................................7 1. Introduction NAT64 gateway [NAT64] is an equipment for data translation between IP v4 and v6 families. With the development of the network, the data transmission volume is being increased rapidly. In order to make the NAT64 more scalable, load-balancing is one of the most important requirements for NAT64 boxes. [STANDBY] has discussed the load balancing mechanism for NAT64, however, the load-balancer mechanism has never been mentioned yet. This memo analyses and summarizes the different prefix selecting policies and load-balancer approaches, Wang Expires June 31, 2010 [Page 2] Internet-Draft Some Considerations on the December 2009 Load-Balancer for NAT64 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. 3. Prefix Selecting Policy During a session a load-balancer enables an IPv6 client to choose a certain NAT64 box by assigning a certain prefix64 for an IPv4 server. E.g., there are two NAT64 boxes (NAT64-A and NAT64-B) providing the data translation service 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 IPv4 server, thus 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 some prefix selecting policies, thus the loads can be evenly distributed on the set of NAT64 boxes. This section provides some prefix selecting policies, three static and one dynamic. These policies are not specific to any load-balancer. 3.1. Source-Based Prefix Selecting Policy A source-based prefix selecting policy allows a load-balancer to choose prefix64s according to the IP address of the requesting client. In the above example, the load-balancer can choose prefix64-A if the IPv6 address of the requesting client is odd, and prefix64-B if even. The advantages and disadvantages of this policy are left for the future exploration. Wang Expires June 31, 2010 [Page 3] Internet-Draft Some Considerations on the December 2009 Load-Balancer for NAT64 3.2. Destination-Based Prefix Selecting Policy A destination-based prefix selecting 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. The advantages and disadvantages of this policy are left for the future exploration. 3.3. Round-Robin Prefix Selecting Policy A round-robin prefix selecting policy allows a load-balancer to choose prefix64s according to the arriving sequence of the requesting client. In the above example, load-balancer can choose prefix64-A to the first arriving requesting client, prefix64-B to the second, prefix64-A to the third, prefix64-B to the fourth, and so on. The advantages and disadvantages of this policy are for the future study. 3.4. Dynamic Prefix Selecting Policy The above three policies are all static prefix selecting 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 dynamic policy requires a load-balancer to timely collect state information of the NAT64 boxes and allocate prefix64s according to their NAT64 boxes' loads, which will bring huge network burden. 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. Wang Expires June 31, 2010 [Page 4] Internet-Draft Some Considerations on the December 2009 Load-Balancer for NAT64 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 the 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 selecting 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. 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 selecting policy. Because having no knowledge of the IP address of the queried IPv4 server, destination-based prefix selecting policy is not suitable in this case. 4.2.2. DHCP 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 selecting policy can be source- based or round-robin or dynamic. Because having no knowledge of the IP address of the IPv4 server which its client wants to communicate Wang Expires June 31, 2010 [Page 5] Internet-Draft Some Considerations on the December 2009 Load-Balancer for NAT64 with, DHCP server can't use destination-based prefix selection policy. 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 selecting 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 selecting 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 selecting policy can be destination-based, source-based (only one prefix64 is used) or round-robin or dynamic. 5. References 5.1. Normative References 5.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 June 31, 2010 [Page 6] Internet-Draft Some Considerations on the December 2009 Load-Balancer for NAT64 [Learn_Prefix] D. Wing, "Learning the IPv6 Prefix of a Network's IPv6/IPv4 Translator", draft-wing-behave-learn-prefix- 03(work in progress), July, 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. 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 Wang Expires June 31, 2010 [Page 7]