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]