Network Working Group G. Chen Internet-Draft H. Deng Intended status: Experimental China Mobile Expires: April 29, 2010 October 26, 2009 A Optimal Load-balance mechanism for NAT64 (OL-NAT) draft-chen-behave-olnat-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 April 29, 2010. 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. Chen & Deng Expires April 29, 2010 [Page 1] Internet-Draft OL-NAT October 2009 Abstract In NAT64 scenaires,sigle-point failure is a critical issue to restrict large-scale deployment. In order to overcome this hurdle, this memo proposed a optimal load-balance mechanism for NAT64. Through the new-defined evaluation metrics, several extended ICMP messages combining with anycast are performed to achieve optimal NAT64 selection. Meanwihle, the synchroniztion process of IP address mapping information is also designed to guarantee the service continuity. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Optimum Load-balance Mechanism Overview . . . . . . . . . . . 4 3. Anycast Load-balance Mechanisms . . . . . . . . . . . . . . . 5 4. Mapping Information Synchronization . . . . . . . . . . . . . 7 5. Optimal Load-balance Data Flow Description . . . . . . . . . . 8 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 8. Informative References . . . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 Chen & Deng Expires April 29, 2010 [Page 2] Internet-Draft OL-NAT October 2009 1. Introduction In NAT64[I-D.bagnulo-behave-nat64] scenaries, NAT64 gateway is a equipment to handle data translation functionalities between different IP families. With the development of network scale, the data transmission volume will be increased rapidly. Meanwhile, a more productive processing capabilities are required to implement IP address translation and application layer gateway processing. Due to the unstable volume of data traffic, a single-point failure is easy to occur in the case of deploying a single gateway on IPv6 network border. In order to provide a reliable NAT handling, some redundancy mechanisms have been designed, such as cold standy and hot standy mechanism. In addition, new routing mechanisms are also proposed to achieve load-balance between different NAT equipments. Those methods could decrease the risks of single-point failures by separating data traffic into different NAT. However,unbalanced traffic distributions could be happened when a specific destination has been trageted frequently. For example, some popular websites always get high visit rating. In order to achieve the results of optimal load-balance, a dynamic load-balance mechanism is required based on NAT process load states. The optimum load-balance mechanism could dynamicaly direct data traffic into the NAT with light data traffic. Therefore, the network resource could be allocated maximally. In the document, an optimal load-balance mechanism of NAT64 is proposed to realize optimized data traffic distribution based on anycast approach. Depending on that, hosts located on IPv6 network could simply configure a specific anycast address to discover a proper NAT64. Chen & Deng Expires April 29, 2010 [Page 3] Internet-Draft OL-NAT October 2009 2. Optimum Load-balance Mechanism Overview Depending on the characteristics of anycast routing, the anycast mechanism was applied in many load-balance cases, such as DNS load- balance. Anycast approach provides hosts with a specific anycast address, which represents a bundle of server with similar functionalities. Based on the anycast routing rules, only a router with minimum hop to the source response the initiator.In another words, the load-balace mechanism based on anycast only treat the hop as a metrics. Following this rules, unbalaced load distribution might be happend in local area, since data only routed to a specific router. The objectives of optimal load-balance mechanism are to discover apropriate NAT to translate IP address information. Therefore, the selection of optimum NAT is an key issue for the load-balance mechanism. Therein, two kinds of basic indicators are considerated to evaluate which NAT could be chosen to process data translation. Under the analysis of influence factors,load status of NAT and hop from hosts to NAT are defined. The load status represents the utilization of NAT processor. And hop could be counted from hosts to NAT by interim routers. The combination of two indicators is used to determine data paths, throgh which data traffic si routed to a destination. Under effect of above defined metrics, the data traffic will be route to optimum NAT dynamically. It could cause the uncertainty of NAT selection, since network environment will be changed over time. When the traffic is directed to different NAT compared to previous one, the IP address mapping information is needed to guarantee transmited data could be tanslated. Therefore, the IP address mapping should be synchronized betweent the different NAT so as to ensure the service continuities. Otherwise, the data traffic will be lost due to the absence of mapping table. Chen & Deng Expires April 29, 2010 [Page 4] Internet-Draft OL-NAT October 2009 3. Anycast Load-balance Mechanisms In order to performe the optimal load-balance using anycast mechanism, following extended ICMP messages are proposed to carry defined indicators. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Code | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identifier | Reserved |A| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Anycast Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Hop | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: NAT anycast request message NAT anycast request message is shown in figure 1. The message is transmitted from a host to NAT64. The flag A indicates this message is dedicated to anycast propagation. Anycast address represents identifier of a bundle of NAT64 equipments. Hop is used to measure the distance from soruce to destination NAT. The field will be added by one through each interim router. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Code | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identifier | Reserved |A| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Unicast Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Unicast Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ................ | Figure 2: NAT anycast response message NAT anycast response message is shown in figure 2. The message is transmitted from NAT64 to a host. The flag A indicates this message Chen & Deng Expires April 29, 2010 [Page 5] Internet-Draft OL-NAT October 2009 is dedicated to anycast propagation. A unicast address is listed in order to show respective unicast address of NAT64. Acoording to given rules, the top Unicast address has high priority. It will be recommend as optimal NAT64 address. Chen & Deng Expires April 29, 2010 [Page 6] Internet-Draft OL-NAT October 2009 4. Mapping Information Synchronization In order to synchronize the IP address mapping infromation between different NAT64, a extend ICMP message is proposed to carry the mapping information. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Code | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identifier | Reserved |A| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Anycast Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Unicast Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv6 Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ................ | Figure 3: NAT anycast synchronization message NAT anycast synchronization message is shown in figure 3. The message is transmitted between different NAT64. The flag A indicates this message is dedicated to anycast propagation. Anycast address represents identifier of a bundle of NAT64 equipments. Unicast Address indicate itself network interface address. The IPv6 address and IPv4 address fields are used to carry IP address mapping information. Chen & Deng Expires April 29, 2010 [Page 7] Internet-Draft OL-NAT October 2009 5. Optimal Load-balance Data Flow Description The optimal Load-balance mechanism will adopt new-defiend ICMP message to achieve the mapping information synchronization and optimal NAT64 selection. The figure 4 is to describe the overall optimal load-balance data flow. Host Router NAT64(A) NAT64(B) NAT64(C) | | | | | synchronization message| (1) | | |----------->--------->| |request message | | | (2) |------->| | | | (3) | Hop plus 1 | | | | |request message | | (4) | |----------->| | | | | | | | | response message | | | (5) |<--------------------| | | Figure 4: Optimal Load-balance Data Flow (1)IP address mapping infromation will be synchronized based on interaction of NAT anycast synchronization message. Each NAT64 will send synchronization message to a NAT64 multicast address, which could guarantee each of them can receive the message and construct global NAT64 mapping table. The synchronization actions will be performed by constant interval in order to update respective changes. (2)Host send a NAT anycast request message to a specific anycast address, which will identify a bundle of NAT64. (3)When a normal router receive the request message, they will update Hop field by plusing one and routed to next hop. (4)When the request message arrive the NAT64 with anycast address, it will extract hop field and combine with load status to determine whether it is optimal NAT64. (5)NAT64 sends NAT anycast response message with recommend NAT64 list to hosts. And, the host will pick the optimal NAT64 unicast address to initiate application data flow. Chen & Deng Expires April 29, 2010 [Page 8] Internet-Draft OL-NAT October 2009 6. Security Considerations It needs to be further identified. Chen & Deng Expires April 29, 2010 [Page 9] Internet-Draft OL-NAT October 2009 7. IANA Considerations This memo request IANA to assign specific ICMP type number to identify the NAT anycast message. Chen & Deng Expires April 29, 2010 [Page 10] Internet-Draft OL-NAT October 2009 8. Informative References [I-D.bagnulo-behave-nat64] Bagnulo, M., Matthews, P., and I. Beijnum, "NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers", draft-bagnulo-behave-nat64-03 (work in progress), March 2009. Chen & Deng Expires April 29, 2010 [Page 11] Internet-Draft OL-NAT October 2009 Authors' Addresses Gang Chen China Mobile 53A,Xibianmennei Ave. Beijing 100053 P.R.China Phone: +86-13910710674 Email: phdgang@gmail.com Hui Deng China Mobile 53A,Xibianmennei Ave. Beijing 100053 P.R.China Phone: +86-13910750201 Email: denghui02@gmail.com Chen & Deng Expires April 29, 2010 [Page 12]