One document matched: draft-xu-behave-nat64-standby-00.txt
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]
| PAFTECH AB 2003-2026 | 2026-04-24 02:53:35 |