Network working group X. XU Internet Draft Huawei Category: Informational Expires: October 2009 April 29, 2009 Redundancy and Load Balance Mechanism of NAT64 draft-xu-behave-nat64-standby-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 October 29, 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. Xu. Expires October 29, 2009 [Page 1] Internet-Draft Redundancy and Load Balance for NAT64 April 2009 Abstract NAT64 [NAT64], a simplified NAT-PT [RFC2766] without DNS-ALG, provides a method for IPv6 hosts to initiate communications with IPv4 hosts. This memo defines several mechanisms supporting redundancy and load balance amongst NAT64 boxes. 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. Scenario Description....................................... 3 4. Redundancy Mechanisms...................................... 4 4.1. Cold Standby Mechanism................................ 4 4.2. Hot Standby Mechanism................................. 5 5. Load Balance Mechanisms.................................... 6 5.1. Load Balance in a Cold Standby Mechanism ............. 6 5.2. Load Balance in a Hot Standby Mechanism............... 6 6. Election Protocol Consideration............................ 7 7. Security Considerations.................................... 7 8. IANA Considerations........................................ 8 9. Acknowledgments............................................ 8 10. References ............................................... 8 Authors' Addresses............................................ 9 Xu. Expires October 29, 2009 [Page 2] Internet-Draft Redundancy and Load Balance for NAT64 April 2009 1. Introduction NAT-PT [RFC2766] is an IPv4/IPv6 translation solution. However, due to the reasons described in [RFC4966], NAT-PT has been reclassified from proposed standard to historic status. NAT64 [NAT64] is a simplified NAT-PT, which provides a scalable method for IPv6 hosts to initiate communications to IPv4 hosts. In this memo, we specify several mechanisms for redundancy and /or load balance among a set of NAT64 boxes. 2. Terminology NAT64: is a translator device that translates communications initiated from the IPv6 side to the IPv4 side. See [NAT64] for more information. Prefix64: is an IPv6 prefix used for synthesizing IPv6 addresses for the IPv4 hosts. See [Prefix64] for more information. 3. Scenario Description In typical operational scenarios, two NAT64 boxes are usually used for redundancy and /or load balance purpose. Therefore, to benefit the discussion, we describe the mechanisms mainly using the scenarios where there are only two boxes (See Figure 1 . Note that the mechanisms proposed in this demo can be easily used in scenarios where there are more than two boxes. +-------------------------+ +------------------------+ | | | | | +---+---+ | | | +---------+ |NAT64-A+---+ +---------+ | | |IPv6 Host| +---+---+ | |IPv4 Host| | | +---------+ | | +---------+ | | | | | | +---+---+ | | | |NAT64-B+---+ | | IPv6 Network +---+---+ | IPv4 Network | | | | | +-------------------------+ +------------------------+ Figure 1 Dual NAT64 Boxes Scenario We assume that IPv6 hosts have already obtained the synthesized IPv6 addresses for IPv4 hosts through one of those approaches described Xu. Expires October 29, 2009 [Page 3] Internet-Draft Redundancy and Load Balance for NAT64 April 2009 in [DNS64], [Learn Prefix64] etc. So we will skip the process of obtaining the synthesized IPv6 addresses and directly specify the redundancy and /or load balance mechanisms. 4. Redundancy Mechanisms This section introduces two standby mechanisms, the cold standby mechanism and the hot standby mechanism. These redundancy mechanisms are able to keep the switchover of the NAT64 boxes transparent to the hosts, especially to the IPv6 hosts, to different extents. The cold standby mechanism doesn't need the mapping states to be synchronized among the NAT64 boxes. With this mechanism, the already established connections (e.g., TCP connections) will be interrupted due to the switchover of NAT64 boxes, but later they can be re- established without the notice of applications on the communicating hosts. The hot standby mechanism in contrast, requires the mapping states to be synchronized in a timely fashion among the involved NAT64 boxes. With this mechanism, the already established connections can be preserved even when the switchover of NAT64 boxes occurs. 4.1. Cold Standby Mechanism For cold standby, the prefix64s used by the NAT64 boxes in Figure 1 (i.e., NAT64-A and NAT64-B) should be identical. However, there should be no overlap in their IPv4 address pools. By running some election protocol (see section 4.1), one is designated as the Master and the other as the Backup. The Master announces a route to that prefix64 on the IPv6 network side and a route to its own IPv4 address pool on the IPv4 network side. The Backup could either announce the route to that prefix64 at much higher cost or not announce it at all on the IPv6 network side, and it could either announce the route to its IPv4 pool or not on the IPv4 network side. The benefit of advertising those routes by the Backup is to achieve fast failover. However, the cost of the route to that prefix64 advertised by the Backup must be set high enough so as to ensure the route advertised by the Master always to be selected as the best by those routers within IPv6 network despite of topology changes, as long as the Master is still available. Since these NAT64 boxes use different IPv4 address pools, there is no such issue on the IPv4 network side. Apart from election protocols, we can also achieve the similar effect through manual configuration. For example, we set one box as the Master and the other as the Backup. The Master announces a route Xu. Expires October 29, 2009 [Page 4] Internet-Draft Redundancy and Load Balance for NAT64 April 2009 to that prefix64 on the IPv6 network side and a route to its own IPv4 address pool on the IPv4 network side. The Backup should announce the route to that prefix64 at a high enough cost on the IPv6 network side and a route to its own IPv4 address pool on the IPv4 network side. Once a NAT64 box, no matter the Master or the Backup, loses connections with the IPv4 network or the IPv6 network, it must withdraw the routes announced previously. Once the Master fails, the route to the prefix64 advertised by the Backup, though with a higher cost, will now be looked as the best by those routers within IPv6 network since the route advertised by the Master has either been withdrawn or unavailable. Since the NAT64 boxes use different IPv4 address pools without any overlap, the already established connections are interrupted when the switchover of the NAT64 boxes occurs. However, the IPv6 hosts can re-establish those connections without the notice of applications on the communicating hosts. 4.2. Hot Standby Mechanism To achieve hot standby, the two NAT64 boxes shown in Figure 1 should use not only the same prefix64 but also the same IPv4 address pool. By running a certain election protocol, a box is designated as the Master, and the other is designated as the Backup. The Master announces a route to the prefix64 on the IPv6 network side and a route to the IPv4 address pool on the IPv4 network side. The Backup doesn't need to announce them at all. To reduce the interrupting duration further during the failover, the Backup could also announce those routes but the costs of them must be set high enough so as to guarantee the route advertised by the Master always to be selected as the best by those routers within IPv6 network despite of topology changes, as long as the Master is still available. Besides the election protocol, we can also achieve the similar effect through manual configuration. For example, we set one box as the Master and the other as the Backup. The Master announces a route to the prefix64 on the IPv6 network side and a route to its IPv4 address pool on the IPv4 network side. The Backup also announces those routes but with much higher costs. Since this mechanism is almost the same as that described in section 3.1.1, we do not go into details. The packets between the IPv4 network and the IPv6 network travel via the Master in normal cases. Meanwhile, the translation mapping states on the Master are synchronized by a certain mapping state synchronization protocol (e.g., Server Cache Synchronization Xu. Expires October 29, 2009 [Page 5] Internet-Draft Redundancy and Load Balance for NAT64 April 2009 Protocol (SCSP) [RFC2334]) to the Backup in a timely fashion. Once the Master fails, the Backup becomes the new Master and takes over the translation and forwarding responsibility to provide uninterrupted service to the hosts. Because the Master and the Backup use the same IP address pool and synchronize the mapping states timely, the established connections will not be interrupted during the switchover of the NAT boxes. 5. Load Balance Mechanisms On the basis of the standby mechanisms mentioned above, we can further realize load balance among a set of NAT64 boxes. The basic idea is as follows: these NAT64 boxes use two prefixe64s(e.g., prefix64-A and prefix64-B), and one box is designated as the Master for prefix64-A and the Backup for prefix64-B and the other as the Backup for prefix64-A and the Master for prefix64-B, and half of the IPv6 hosts use prefix64-A and half are using prefix64-B. In this way, the IPv6 packets towards IPv4 network is balanced among a set of NAT64 boxes according to their destination addresses with different prefix64. Note that the both outbound and inbound packets of the same connection will pass through the same NAT64 box. This demo does not discuss the issues with achieving best balance by adjusting the numbers of hosts adopting different prefix64s. Interested readers are referred to [DNS64] and [Learn Prefix64] for more details. 5.1. Load Balance in a Cold Standby Mechanism To achieve load balance in a cold standby mechanism, there are two options for NAT64s. One option is to use the same IPv4 address pool corresponding to different prefix64. In this case, a NAT64 box needs to determine which prefix64 should be used when translating a received IPv4 packet to a IPv6 packet. So the prefix64 used by each connection should be recorded in its NAT mapping table. Another option is to use different IPv4 address pools corresponding to different prefix64s. In this way, the NAT64 box could easily determine which prefix64 should be used according to which IPv4 address pool the destination address belongs to. 5.2. Load Balance in a Hot Standby Mechanism As for load balance in a hot standby mechanism, the NAT64 box should use different IPv4 address pools corresponding to different prefix64s. Otherwise, the inbound IPv4 packets may pass through a Xu. Expires October 29, 2009 [Page 6] Internet-Draft Redundancy and Load Balance for NAT64 April 2009 different NAT64 box than that the outbound IPv6 packets of the same connection pass through. When translating a received IPv4 packet to an IPv6 packet, the NAT64 box could easily determine which prefix64 should be used according to which IPv4 address pool the destination address belongs to. 6. Election Protocol Consideration The election protocol is used to dynamically designate one from a set of NAT64 boxes as the Master, which is responsible for IPv4/IPv6 translation and forwarding. Once the election is done, the Master will announce a route to the prefix64 on the IPv6 side and a route to the IPv4 address pool on the IPv4 side, and the Backup will either announce those routes at much higher costs or not announce them at all. If the Master becomes unavailable then the Backup with the highest priority will transit to Master after a short delay. The election protocol will also track the NAT64 box's connectivity to the IPv4 network and the IPv6 network, once the NAT64 box loses connection to the IPv4 network or the IPv6 network, its priority is set to zero, which means it is not suitable to be a candidate for the Master any more and it will withdraw the route to the prefix64 and the route to the IPv4 address pool advertised previously. In fact, we can use the VRRP [RFC2338] directly as the automatic election protocol. If two NAT64 boxes are directly connected via an Ethernet network, the VRRP can run directly on the Ethernet interfaces. Otherwise, some extra configurations or protocol changes need to be implemented. One option is to create conditions for the VRRP to run among these boxes. For example, we create a VPLS [RFC4761, RFC4762] instance and enable IP functions and run VRRP on those VLAN interfaces which are bounded to that VPLS instance. If enabling IP function on those interfaces bound to VPLS instances is not supported, we can use the following trick to realize the same goal, but at a cost of consuming two physical interfaces on each NAT64 box. The approach is: create a VPLS instance among a set of NAT boxes, and on each of them one Ethernet interface is bound to that VPLS instance, another IP enabled Ethernet interface is locally connected with that interface. Then the VRRP can run on those IP enabled Ethernet interfaces which are connected through that VPLS instance. Another option is to do some change to the VRRP so that VRRP neighbors can be configured manually and VRRP messages can be exchanged directly between two neighbors in a unicast fashion 7. Security Considerations TBD. Xu. Expires October 29, 2009 [Page 7] Internet-Draft Redundancy and Load Balance for NAT64 April 2009 8. IANA Considerations TBD. 9. Acknowledgments The author would like to thank Dacheng Zhang and Xuewei Wang for their valuable comments and reviews. 10. References [RFC2766] Tsirtsis, G. and P. Srisuresh, "Network Address Translation - Protocol Translation (NAT-PT)", RFC 2766, February 2000. [RFC4966] Aoun, C. and E. Davies, "Reasons to Move the Network Address Translator - Protocol Translator (NAT-PT) to Historic Status", RFC 4966, July 2007. [RFC2338] Knight, S., et. al., "Virtual Router Redundancy Protocol", RFC2338, April 1998. [RFC2334] Luciani, J., Armitage, G., Halpern, J., and N. Doraswamy, "Server Cache Synchronization Protocol (SCSP)", RFC 2334, April 1998. [RFC4761] Kompella, K. and Y. Rekhter, "Virtual Private LAN Service (VPLS) Using BGP for Auto-Discovery and Signaling",RFC 4761, January 2007. [RFC4762] Lasserre, M. and Kompella, V. (Editors), "Virtual Private LAN Service (VPLS) Using Label Distribution Protocol (LDP) Signaling", RFC 4762, January 2007. [NAT64] Bagnulo, M., Matthews, P., and I. Beijnum, "NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers", draft-bagnulo-behave-nat64-02 (work in progress), November 2008. [Prefix64] Miyata, H., "PREFIX64 Comparison", draft-miyata-behave- prefix64-00 (work in progress), October 2008. [Learn Prefix64] Wing, D., "Learning the Address Family Translator's IPv6 Prefix", draft-wing-behave-learn-prefix-01 (work in progress), March 2009. Xu. Expires October 29, 2009 [Page 8] Internet-Draft Redundancy and Load Balance for NAT64 April 2009 Authors' Addresses Xiaohu Xu Huawei Technologies, No.3 Xinxi Rd., Shang-Di Information Industry Base, Hai-Dian District, Beijing 100085, P.R. China Phone: +86 10 82836073 Email: xuxh@huawei.com Xu. Expires October 29, 2009 [Page 9]