Network working group X. XU
Internet Draft Huawei
Category: BCP
Expires: December 2009 June 9, 2009
Redundancy and Load Balancing Mechanisms for Stateful Network
Address Translators (NAT)
draft-xu-behave-stateful-nat-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 December 9, 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 December 9, 2009 [Page 1]
Internet-Draft Redundancy and Load Balancing June 2009
Mechanism for Stateful NAT
Abstract
This document defines some redundancy and/or load balancing
mechanisms for stateful Network Address Translators (NAT), including
IPv4->IPv4 NAT, IPv4->IPv6 NAT and IPv6->IPv4 NAT.
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.........................................4
4. Redundancy Mechanisms........................................5
4.1. Cold Standby Mechanism..................................5
4.2. Hot Standby Mechanism...................................6
5. Load Balancing Mechanisms....................................7
6. Election Protocol Consideration..............................8
7. State Synchronization Protocol Consideration.................8
8. Security Considerations......................................9
9. IANA Considerations..........................................9
10. Acknowledgments.............................................9
11. References..................................................9
Authors' Addresses.............................................10
Xu. Expires December 9, 2009 [Page 2]
Internet-Draft Redundancy and Load Balancing June 2009
Mechanism for Stateful NAT
1. Introduction
Network Address Translation (NAT) has been used as an efficient way
to delay IPv4 address exhaustion and been deemed as a major
mechanism for IPv4/IPv6 transition and coexistence. In the Large
Scale NAT (LSN) scenarios as described in some proposals, e.g.,
[NAT444], [DS-Lite] and [NAT64], the LSN routers are deployed in
large-scale networks (e.g., ISP networks, campus networks or
enterprise networks) and serve a huge amount of users. Hence
redundancy and/or load-balancing capabilities are strongly desired
for these LSN routers in order to provide high availability services
to users. However, a failure of stateful NAT, which maintains states
per session, would cause interruption of those sessions.
In this document, we describe some redundancy and/or load balancing
mechanisms for stateful NAT, including IPv4->IPv4 NAT, IPv4->IPv6
NAT and IPv6->IPv4 NAT. Note that stateless NAT is out of the scope
of this document. Unless mentioned otherwise, NAT and LSN throughout
this document will pertain to stateful NAT and stateful LSN
separately.
2. Terminology
The majority of terms used in this document are borrowed almost as
is from [RFC2633], the following are some terms specific to this
document.
LSN (Large-Scale NAT): a NAT device placed at the border between
large-scale user networks (e.g., ISP network, enterprise network, or
campus network) and the Internet.
LSN internal address realm (internal realm for short): a realm where
the communication initiators (e.g., a client in the client/server
application) are located. For IPv4->IPv4 NAT, the internal realm
refers to the private networks, as opposed to the IPv4 Internet. For
IPv6->IPv4 NAT, the internal realm means IPv6 network or IPv6
Internet. For IPv4->IPv6 NAT, the internal realm refers to IPv4
network or IPv4 Internet. Accordingly, the hosts located in the
internal realm are called internal hosts, and the addresses used in
the internal realm are called internal addresses.
LSN external address realm (external realm for short): a realm where
the communication responders (e.g., a server in the client/server
application) are located. For IPv4->IPv4 NAT, the external realm
refers to the IPv4 Internet. For IPv6->IPv4 NAT, the external realm
Xu. Expires December 9, 2009 [Page 3]
Internet-Draft Redundancy and Load Balancing June 2009
Mechanism for Stateful NAT
means the IPv4 Internet or IPv4 network. For IPv4->IPv6 NAT, the
external realm refers to the IPv6 Internet or IPv6 network.
Accordingly, the hosts located in the external realm are called
external hosts, and the addresses used in the external realm are
called external addresses.
Internal address pool: an address pool used for assigning internal
addresses for the external hosts. Note that this address pool is
specific to IPv4->IPv6 NAT and IPv6->IPv4 NAT. For IPv4->IPv6 NAT,
the IPv4 address pool used for assigning internal IPv4 addresses for
external IPv6 hosts is the internal address pool. For IPv6->IPv4 NAT,
the prefix64 used for synthesizing internal IPv6 addresses for
external IPv4 hosts could be looked as a special internal address
pool.
External address pool: an address pool used for assigning external
addresses for the internal hosts. For IPv4->IPv4 NAT and IPv6->IPv4
NAT, the IPv4 address pool is the external address pool. For IPv4-
>IPv6 NAT, the prefix64 could be looked as a special external IPv6
address pool from which synthesized IPv6 addresses are assigned to
internal IPv4 hosts.
CPE (Customer Premises Equipment): a router in front of internal
hosts.
Prefix64: an IPv6 prefix used for synthesizing IPv6 addresses for
the IPv4 hosts. See [Prefix64] for more details.
3. Scenario Description
+-------------------------+ +-----------------------+
| | | |
| +-+-----+-+ |
| | NAT-A | |
+----+-------------+ +-+-----+-+ +-------------+ |
|CPE/Internal Host | | | |External Host| |
+----+-------------+ | | +-------------+ |
| +-+-----+-+ |
| | NAT-B | |
| Internal realm +-+-----+-+ External realm |
| | | |
+-------------------------+ +-----------------------+
Figure 1. General Scenario of Dual NAT Routers
Xu. Expires December 9, 2009 [Page 4]
Internet-Draft Redundancy and Load Balancing June 2009
Mechanism for Stateful NAT
In a typical operational scenario as illustrated in Figure 1, two
NAT routers are usually deployed for redundancy and/or load
balancing purposes. Hence we will describe the corresponding
mechanisms based on this scenario. Note that these mechanisms are
also suitable in the scenarios in which more than two NAT routers
are used.
Due to the fact that the redundancy and load-balancing mechanisms
for IPv4->IPv4 NAT, IPv4->IPv6 NAT and IPv6->IPv4 NAT are almost the
same except for the routes towards the external realm advertised
into the internal realm by the NAT routers, e.g., a route to the
prefix64 in the case of IPv6->IPv4 NAT, a route to the IPv4 Internet
(in [NAT444]) or the tunnel concentrator (in [DS-Lite]) in the case
of IPv4->IPv4 NAT, and a route to the IPv4 address pool in IPv4-
>IPv6 NAT, we will try to describe these mechanisms in general.
4. Redundancy Mechanisms
The basic idea of NAT redundancy is to make two NAT routers function
as a redundancy group, and select one as the Master and the other as
the Backup through some election protocol (see section 6) or
manually configuration. In normal case, the packets between the
internal realm and the external realm traverse via the Master. Once
the Master fails, the Backup takes over the translation role.
There are two redundancy mechanisms: a cold standby mechanism and a
hot standby mechanism. The goal of the cold standby mechanism is to
keep the NAT failover transparent to the communicating internal
hosts. In contrast, the purpose of the hot standby mechanism is to
remain the established sessions continuous during the NAT failover.
The following sections will describe them separately.
4.1. Cold Standby Mechanism
To achieve cold standby, the internal addresses for external hosts
(as communication responders) should be remained despite the NAT
failover. In IPv4->IPv4 NAT, the external hosts' internal addresses
are the same as their external addresses, so the above requirement
can be met naturally. In IPv6->IPv4 NAT, NAT routers belonging to a
redundancy group should be configured with an identical prefix64. In
IPv4->IPv6 NAT, NAT routers in a redundancy group should be
configured with an identical IPv4 address pool, besides, the state
information should be synchronized among these NAT routers through
some state synchronization protocol (see section 7) so as to ensure
the Backup, once selected as the current Master, could assign the
Xu. Expires December 9, 2009 [Page 5]
Internet-Draft Redundancy and Load Balancing June 2009
Mechanism for Stateful NAT
communicating IPv6 hosts the same IPv4 addresses as those assigned
by the previous Master.
Of the NAT routers in a redundancy group each is configured with a
different external address pool and announces into the external
realm a route to that external address pool. In the cases of IPv4-
>IPv4 NAT and IPv6->IPv4 NAT, NAT routers each are configured with
different external IPv4 address pools without any overlap. Otherwise,
the same address or address/port pair, which was assigned to some
internal host by the previous Master, may be occasionally assigned
to a different internal host by the current Master, this occasion
will cause some confusions. For example, the return packets towards
host A will be misunderstood by the current Master as those towards
host B. In the case of IPv4->IPv6 NAT, each NAT router is configured
with a different prefix64.
In order to make packets towards the external realm always traverse
via the Master, the Master should announce into the internal realm a
route towards the external realm. In case the Master and the Backup
are specified manually, the Backup should also announce into the
internal realm a route towards the external realm to prepare for the
takeover. However, in order to ensure the route advertised by the
Master, rather than that advertised by the Backup, is selected as
the best by the routers in the internal realm despite topology
changes, the route advertised by the Backup should be set at higher
enough cost or larger granularity (For example, the Backup announces
a route to 10.0.0.0/8, while the Master announces two specific
routes to 10.0.0.0/9 and 10.128.0.0/9 respectively). Once the
connections to the external realm lost, the Master should withdraw
the route towards the external realm previously announced. When the
Master fails, packets towards the external realm will pass through
the Backup. If the Master and the Backup are automatically elected
through some election protocol, the Backup would be elected as a new
Master when the old Master fails, so it's not necessary for the
Backup to make the above route announcement.
4.2. Hot Standby Mechanism
To preserve the established sessions during the failover, in
addition to remain the internal addresses for the external hosts
unchanged, the external addresses for the internal hosts should also
keep unchanged. How to meet the first requirement will not be
reiterated since it is the same as that for the cold standby
mechanism. To meet the second requirement, NAT routers in a
redundancy group should be configured with an identical external
address pool and they should assign the same external address for
Xu. Expires December 9, 2009 [Page 6]
Internet-Draft Redundancy and Load Balancing June 2009
Mechanism for Stateful NAT
identical internal hosts. In the case of IPv4->IPv6 NAT, NAT routers
should simply be configured with an identical prefix64. For IPv4-
>IPv4 NAT and IPv6->IPv4 NAT, in addition that the NAT routers are
configured with identical IPv4 address pools, the state on the
Master should be synchronized to the Backup in a timely fashion.
The Master announces into the internal realm a route towards the
external realm and announces into the external realm a route towards
the external address pool. If the Master and the Backup are
specified manually, the Backup should also announce those routes,
but with higher enough cost or larger granularity. Once the
connections to either the external realm or the internal realm lost,
the Master should withdraw the above routes. When the Master fails,
the packets towards the external realm will pass through the Backup.
If the Master and the Backup are automatically elected through some
election protocol, the Backup would be elected as a new Master when
the old Master fails, so it's not necessary for the Backup to make
the above route announcement.
5. Load Balancing Mechanisms
Based on the above redundancy mechanisms, one can further realize
load balancing among a group of NAT routers. The basic idea is to
create two redundancy groups (e.g. group A and group B) on these NAT
routers, make one router as the Master for group A and the Backup
for group B, while make the other as the Master for group B and the
Backup for group A. Taking IPv6->IPv4 NAT as an example, NAT routers
are configured with two prefix64s (e.g., prefix64-A and prefix64-B)
corresponding to two different redundancy group (e.g., group A and
group B)separately, and one router is designated as the Master for
group A and the Backup for group B, while the other as the Backup
for group A and the Master for group B. In this way, the IPv6
packets towards the IPv4 external realm are balanced among these NAT
routers according to their destination addresses with different
prefix64s.
For load balancing together with the cold standby, each NAT router
could either use the same external address pool or different
external address pools corresponding to these redundancy groups.
However, the external address pools on different NAT routers
shouldn't have any overlap. Otherwise, the same address or
address/port pair could be assigned occasionally to different
internal hosts. In contrast, for load balancing together with the
hot standby, different external address pools should be configured
for these redundancy groups. Otherwise, the return packets towards
the internal realm may be forwarded to a wrong NAT router.
Xu. Expires December 9, 2009 [Page 7]
Internet-Draft Redundancy and Load Balancing June 2009
Mechanism for Stateful NAT
6. Election Protocol Consideration
Election protocol is used to automatically elect one from a
redundancy group as the Master NAT router and the other as the
Backup NAT routers. Once the Master fails, the Backup with the
highest priority will take over the Master role after a short delay.
The election protocol will also be used to track the connectivity to
the external realm and the internal realm. Once connections to the
external realm or the internal realm lost, the NAT router is not
qualified to the Master and it will withdraw the route towards the
external realm announced previously, in the case of hot standby, it
should also withdraw the route towards the internal address pool.
In fact, one can use the VRRP [RFC2338] directly as the automatic
election protocol. In addition, the interface track mechanism can
also be used to adjust the priority to influence the election
results.
If two NAT routers are directly connected via an Ethernet network,
the VRRP can run directly on the Ethernet interfaces. Otherwise,
some extra configuration or protocol changes need to be implemented.
One option is to create conditions for VRRP to run among these
routers. For example, we create a VPLS [RFC4761, RFC4762] instance
and enable IP functions and run VRRP on those VLAN interfaces which
are bound to that VPLS instance. If enabling IP function on those
interfaces is not supported, one can use the following trick to
realize the same goal, but at a cost of consuming two physical
interfaces on each NAT router. The approach is: create a VPLS
instance among a set of NAT routers, and on each of them one
Ethernet interface is bound to that VPLS instance, and another IP
enabled Ethernet interface is locally connected with that interface.
Then VRRP can run on those IP enabled Ethernet interfaces which are
all connected to that VPLS instance. Another option is to do some
change to VRRP so that VRRP neighbors can be configured manually and
VRRP messages can be exchanged directly between two neighbors in a
unicast fashion.
7. State Synchronization Protocol Consideration
The Server Cache Synchronization Protocol (SCSP) defined in [RFC2334]
could be used as a candidate for state synchronization protocol.
Details about the usage and possible modifications will be explored
in the next version of this document.
Xu. Expires December 9, 2009 [Page 8]
Internet-Draft Redundancy and Load Balancing June 2009
Mechanism for Stateful NAT
8. Security Considerations
TBD.
9. IANA Considerations
TBD.
10. Acknowledgments
The author would like to thank Dan Wing, Dave Thaler for their
insightful comments and reviews, and thank Dacheng Zhang and Xuewei
Wang for their valuable editorial reviews.
11. References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network
Address NAT (Traditional NAT)", RFC 3022, January 2001.
[RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address
NAT (NAT) Terminology and Considerations", RFC
2663, August 1999.
[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 NAT - Protocol NAT (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.
Xu. Expires December 9, 2009 [Page 9]
Internet-Draft Redundancy and Load Balancing June 2009
Mechanism for Stateful NAT
[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, "NAT: Network
Address and Protocol Translation from IPv6 Clients to IPv4
Servers", draft-bagnulo-behave-NAT64-03 (work in progress),
March 2009.
[NAT444] Shirasaki, Y., Miyakawa, S., Nakagawa, A., Yamaguchi, J.,
and H. Ashida, "NAT444 with ISP Shared Address",
draft-shirasaki-nat444-isp-shared-addr-00 (work in
progress), October 2008.
[DS-Lite] Durand, A., "Dual-stack lite broadband deployments post
IPv4 exhaustion", draft-ietf-softwire-dual-stack-lite-00
(work in progress), March 2009.
[Prefix64] Miyata, H., "PREFIX64 Comparison", draft-miyata-behave-
prefix64-00 (work in progress), October 2008.
[LSN] Nishitani,T., Miyakawa, S., Nakagawa, A., Ashida,H., " Common
Functions of Large Scale NAT (NAT)", draft-nishitani-cgn-
01 (work in progress), November 2008
[Framework] Baker, F., Li,X., Bao,C., "Framework for IPv4/IPv6
Translation", draft-baker-behave-v4v6-framework-02 (work
in progress), February 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 December 9, 2009 [Page 10]