Network working group                                          D. Cheng
Internet Draft                                                    X. Xu
Category: Standard Track                                         Huawei
Expires: February 2011                                       J. Halpern
                                                               Ericsson
                                                           M. Boucadair
                                                         France Telecom
                                                        August 24, 2010

                   NAT State Synchronization Using SCSP

                     draft-xu-behave-nat-state-sync-02


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 February 24, 2011.

Copyright Notice

   Copyright (c) 2010 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
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document. Please review these documents





Xu, et al.            Expires February 24, 2011               [Page 1]


Internet-Draft     NAT State Synchronization Using SCSP     August 2010

   carefully, as they describe your rights and restrictions with
   respect to this document.

Abstract

   To support NAT redundancy in hot standby mode [NAT-STANDBY] among a
   group of NAT devices, the dynamic NAT entries created at the primary
   NAT device should be synchronized consistently to the backup NAT
   device.  This document describes a method of using the Server Cache
   Synchronization Protocol (SCSP) for NAT state synchronization and
   specifies the corresponding NAT specific components for this method.

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
      1.1. Overall Context.........................................3
      1.2. Proposed Procedure at a Glance..........................4
      1.3. NAT State Information Description.......................5
   2. Format of NAT CSA Record Specific Part.......................6
      2.1. NAT44 Specific Fields in CSA Record.....................8
      2.2. NAT64 Specific Fields in CSA Record.....................9
      2.3. NAT46 Specific Fields in CSA Record.....................9
   3. Values for SCSP Protocol Independent Part...................10
      3.1. Values for the SCSP "Mandatory Common Part"............10
      3.2. Values for the SCSP "CSAS Record"......................10
   4. Security Considerations.....................................11
   5. IANA Considerations.........................................11
   6. Acknowledgments.............................................11
   7. References..................................................11
      7.1. Normative References...................................11
      7.2. Informative References.................................11
   Authors' Addresses.............................................12










Xu, et al.            Expires February 24, 2011               [Page 2]


Internet-Draft     NAT State Synchronization Using SCSP     August 2010


1. Introduction

1.1. Overall Context

   Network Address Translation (NAT) [RFC3022] is a technique which has
   been introduced to share the same IPv4 address between several users.
   As a side effect, NAT can be used as a means to use global IPv4
   addresses effectively by placing NAT devices between end-users and
   public network. Other variants of NAT have been emerged particularly
   in the context of IPv4-IPv6 interconnection and also to solve the
   global IPv4 address shortage problem leading to various
   configurations as the ones listed hereafter:

       - NAT444 [NAT444]

       - DS-Lite [DS-LITE]

       - NAT64 [NAT64]

   NAT function can be implemented on routers or standalone nodes. In
   this memo, the term "NAT device" does not refer to a given
   implementation scheme (whether embedded in a router or not).Besides,
   the NAT mentioned in this document refers to stateful NAT, i.e.,
   stateless NAT is outside the scope of this document.

   High availability is very desirable for NAT devices that operate in
   carriers' networks. One method for achieving this is to deploy two
   or more NAT devices within a redundancy group, as proposed in [NAT-
   STANDBY]. When these NAT devices are deployed in hot-standby mode
   (see [NAT-STANDBY] for more details), the associated translation
   states that are maintained on the primary NAT device MUST be
   synchronized to the backup NAT device(s). Therefore, in case the
   primary NAT device fails, the backup NAT device can continue
   performing translation function for arriving IP traffic. Note that
   the primary and its backup NAT device(s) mentioned here is specific
   to a given redundancy group, which is a group of NAT devices
   deployed within a network domain to perform NAT function with
   redundancy.

   The NAT states mentioned in this document only mean those NAT states
   which are created dynamically, rather than those static NAT states
   which are configured manually on NAT devices. For those static NAT
   states, they are essentially part of the configuration data. The
   replication of configuration data among a group of devices is
   absolutely outside the scope of this document.




Xu, et al.            Expires February 24, 2011               [Page 3]


Internet-Draft     NAT State Synchronization Using SCSP     August 2010

1.2. Proposed Procedure at a Glance

   The Server Cache Synchronization Protocol (SCSP) [RFC2334] solves
   the general server synchronization/cache-replication problem for
   distributed databases. This document specifies a method of using
   SCSP to achieve NAT state synchronization among the NAT devices in a
   redundancy group. SCSP can be decomposed into two parts: (1) the
   protocol independent part and (2) the client/server protocol
   specific part. The protocol independent part is specified in
   [RFC2334], whereas the client/server protocol specific part, to
   which NAT functions corresponding to, is defined in Section 2 of
   this document. Values for fields of the SCSP Protocol Independent
   Part are defined in Section 3.

   Note that SCSP uses exactly the same link state algorithm that is
   used by routing protocols including OSPF and IS-IS, to perform
   reliable and robust flooding among participating nodes, among which
   database gets synchronized in a very effective manner.

   All NAT devices that belong to a redundancy group are said to belong
   to a Server Group (SG), and the identifier of a SG (SGID) is
   provisioned by the administrative entity which manages the NAT
   devices. If multiple redundancy groups are created among a group of
   NAT devices and the members of the redundancy group accords to the
   members of the physical NAT device group, these redundancy groups
   could share the same SGID for simplicity. For each type of NAT (e.g.,
   NAT44, NAT64, etc.), a separate SCSP Protocol ID (PID) MUST be
   assigned by IANA. A pair of SGID and PID uniquely identifies a
   specific NAT translation table that resides on a group of NAT
   devices, respectively, and is the target to be synchronized by using
   SCSP. All SCSP packets contain a PID and a SGID ([RFC2334]).

   Note that only a primary NAT device can create a new cache entry
   when receiving a user packet, if the corresponding NAT mapping
   information is not already stored. A backup NAT device MUST not
   originate any cache entry other than receiving cache entries from
   the primary through SCSP.

   After the synchronization is completed, the newly elected primary
   NAT device MUST re-originate all cache entries that were originated
   by the previous primary NAT device. In doing so, the NAT mapping
   information in these entries MUST be kept with the same value as
   before, but with the "Originator ID" changed to the identifier of
   its own. These re-originated cache entries are then flooded to the
   other participating NAT devices following SCSP. Optimization during
   this process is possible, e.g., an old cache entry may be with
   higher priority in this process when IP packets with the associated



Xu, et al.            Expires February 24, 2011               [Page 4]


Internet-Draft     NAT State Synchronization Using SCSP     August 2010

   IP flow arrives; details for achieving such optimization is beyond
   the scope of this document. Also in this process, it is assumed that
   all other NAT devices in the same redundancy group would recognize
   the newly elected primary NAT device, and with this information, a
   backup NAT device would replace any cache entry by a new one based
   on the new "Originator ID" during the flooding procedure. Given the
   fact that the NAT mapping information is the same between the new
   and old cache entry that associated with a given IP flow, IP packets
   arrived before and after the replacement of CSAS (Cache State
   Advertisement Summary) record would be handled consistently at a NAT
   device.

   With regard to NAT state refreshment, as long as the primary is
   still alive, the entries originated by it will be available except
   that they are withdrawn explicitly by the primary due to their timer
   expiration. Once the primary fails due to some reason, each NAT
   device in the same redundancy group will start an expiration timer
   for those entries originated by the failed primary. When the timer
   expires, all those entries will be released. An exception is for the
   newly elected primary, that is, even though the timer for those
   entries expires, they can not be released until they have been re-
   originated by the current primary.

   [NAT-STANDBY] is only an example of how to achieve traffic
   redirection and election on primary/backup among a group of NAT
   devices, the approach defined in this document is decoupled with the
   [NAT-STANDBY]. That is to say, the approach defined in this document
   can be used with mechanisms other than the one described in [NAT-
   STANDBY]. The election of a primary NAT device, failover mechanism
   and traffic redirection are beyond the scope of this document.

1.3. NAT State Information Description

   Taken IPv4 to IPv4 NAT as an example, the NAT state entry for a TCP
   session can be represented as:

       Private address

       Private port

       Public address

       Public port

       Remote address

       Remote Port



Xu, et al.            Expires February 24, 2011               [Page 5]


Internet-Draft     NAT State Synchronization Using SCSP     August 2010

       TCP state

       TCP timestamp

       Expiration Timer

   whereas the NAT state entry for a UDP session can be represented as:

       Private address

       Private port

       Public address

       Public port

       Expiration Timer

   Note that only fully established TCP sessions are communicated, and
   therefore there is no need for SCSP to synchronize the "TCP state".
   Since the state refreshment can be dealt with as the OSPF does,
   there is no need for SCSP to synchronize the "Expiration Timer".

2. Format of NAT CSA Record Specific Part

   CSA ([RFC2334]) Record that is specific to NAT is defined as below.

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Protocol      | Option Length |            Unused             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |      Port Mapped from         |        Port Mapped to         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      /                                                               /
      /          Address Mapped from (Specific to NAT type)           /
      /                                                               /
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      /                                                               /
      /           Address Mapped to (Specific to NAT type)            /
      /                                                               /
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      /                                                               /
      /                 TLV Options (Variable Length)                 /
      /                                                               /
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+




Xu, et al.            Expires February 24, 2011               [Page 6]


Internet-Draft     NAT State Synchronization Using SCSP     August 2010

   Protocol (8 bits)

        This field contains the same value of the "Protocol" field as
        carried in the header of IP datagram, of which, the address and
        port number are mapped from by a NAT device. The possible
        values for this field include: TCP, UDP, SCTP and DCCP.

   Option Length (8 bits)

        The total length of the TLV options in byte.

   Port Mapped from (16 bits)

        The TCP/UDP/SCTP/DCCP port number before being mapped.

   Port Mapped to (16 bits)

        The TCP/UDP/SCTP/DCCP port number after being mapped.

   Address Mapped from

        Specific to NAT type, as determined by the SCSP PID, so it will
        be defined in the following separate section for each NAT type.

   Address Mapped to

        Specific to NAT type, as determined by the SCSP PID, so it will
        be defined in the following separate section for each NAT type.

   TLV Option (Variable Length)

        Any additional information associated with the NAT translation
        state entry (e.g., the remote address/port for a TCP session)
        can be encoded in a TLV option if necessary. The TLV format is
        as below. A set of example TLVs (e.g., the remote address and
        the remote port of a TCP session) will be defined in the next
        version of the draft.

       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      |     Length    |                               /
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               /
      /                                                               /
      /                    Value (Variable Length)                    /
      /                                                               /
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



Xu, et al.            Expires February 24, 2011               [Page 7]


Internet-Draft     NAT State Synchronization Using SCSP     August 2010

2.1. NAT44 Specific Fields in CSA Record

   This section defined the specific fields in the CSA Record for NAT44
   including the DS-Lite variant (Note that whether or not NAT44 case
   should be considered in this document will be determined according
   to further comments and feedbacks).

      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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                     Address Mapped from                       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                     Address Mapped to                         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Address Mapped from (32 bits)

        The IPv4 address which is the original one of the internal IPv4
        host. This address is also called internal IPv4 address of the
        internal IPv4 host.

   Address Mapped to (32 bits)

        The IPv4 address which is dynamically allocated for the
        internal IPv4 host by the NAT44. This IPv4 address is also
        called external IPv4 address of the internal IPv4 host.

   Tunnel ID TLV Option (144 bits)

        In the case of DS-Lite [DS-LITE], overlapping address spaces
        used by different subscribers are disambiguated through the
        identification of tunnel endpoints. Hence a TLV option for the
        tunnel endpoint identification (shown as below) is included in
        the NAT specific CSA record. The Tunnel ID field contains the
        IPv6 address of the tunnel endpoint.

      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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     0x01      |     0x10      |                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
      |                                                               |
      +                                                               +
      |                       Tunnel ID                               |
      +                                                               +
      |                                                               |
      +                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



Xu, et al.            Expires February 24, 2011               [Page 8]


Internet-Draft     NAT State Synchronization Using SCSP     August 2010

      |                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

2.2. NAT64 Specific Fields in CSA Record

   This section defined the specific fields in the CSA Record for NAT64.

      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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      +                                                               +
      |                                                               |
      +                     Address Mapped from                       +
      |                                                               |
      +                                                               +
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                     Address Mapped to                         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   Address Mapped from (128 bits)

        The IPv6 address which is the original IPv6 address of the IPv6
        host. This address is also called the internal IPv6 address of
        the internal IPv6 host.

   Address Mapped to (32 bits)

        The IPv4 address which is assigned dynamically for the IPv6
        host by the NAT64. This address is also called the external
        IPv4 address of the internal IPv6 host.

2.3. NAT46 Specific Fields in CSA Record

   This section defined the specific fields in the CSA Record for NAT46.

      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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                     Address Mapped from                       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      +                                                               +
      |                                                               |
      +                     Address Mapped to                         +



Xu, et al.            Expires February 24, 2011               [Page 9]


Internet-Draft     NAT State Synchronization Using SCSP     August 2010

      |                                                               |
      +                                                               +
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Address Mapped from (32 bits)

        The IPv4 address which is dynamically allocated by the NAT46
        for the IPv6 host. This address is also called internal IPv4
        address of the external IPv6 host.

   Address Mapped to (128 bits)

        The IPv6 address which is the original address of the IPv6 host.
        This address is also called external IPv6 address of the
        external IPv6 host.

3. Values for SCSP Protocol Independent Part

   The following sections give values for fields of the SCSP Protocol
   Independent Part of various SCSP messages.

3.1. Values for the SCSP "Mandatory Common Part"

   Protocol ID = TBD

   There is a separate Protocol ID for NAT44, NAT64, and NAT46,
   respectively,assigned by IANA.

   Sender ID Len = 4, if IPv4 address is used, or 16, if IPv6 address
   is used. Per [RFC2334], an identifier assigned to a server (in this
   case, a NAT device), might be the protocol address of the sending
   server.

   Recvr ID Len = 4, if IPv4 address is used, or 16, if IPv6 address is
   used. Per [RFC2334], an identifier assigned to a server (in this
   case, a NAT device), might be the protocol address of the receiving
   server.

3.2. Values for the SCSP "CSAS Record"

   Cache Key Len = 4

   This 4-byte opaque string is generated by the NAT device that
   originates the CSAS.





Xu, et al.            Expires February 24, 2011              [Page 10]


Internet-Draft     NAT State Synchronization Using SCSP     August 2010

   Orig ID Len = 4, if IPv4 address is used, or 16, if IPv6 address is
   used. Per [RFC2334], an identifier assigned to a server (in this
   case, a NAT device) might be the protocol address of the server.

   See Section B.2.0.2 of [RFC2334] for a detailed description of these
   fields.

4. Security Considerations

   SCSP provides some base security features but only for the Protocol
   Independent part ([RFC2334]), with no mechanism to protect the CSA
   record.

5. IANA Considerations

   This document requires new values for the field of Protocol ID as
   defined in [RFC2334], one for each NAT technology, i.e., NAT44,
   NAT64, and NAT46, respectively.

6. Acknowledgments

   Thanks to Simon Perreault, Dan Wing, Marcelo Bagnulo Braun, Reinaldo
   Penno and Cameron Byrne for their comments.

7. References

7.1. Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
             Requirement Levels", BCP 14, RFC 2119, March 1997.

7.2. Informative References

   [RFC2334] Luciani, J., Armitage, G., Halpern, J. and N. Doraswamy,
             "Server Cache Synchronization Protocol", RFC 2334, April
             1998.

   [RFC3022] Srisuresh, P., Egevang, K., "Traditional IP Network
             Address Translator (Traditional NAT)", RFC 3022, January
             2001.

   [NAT444] Shirasaki, Y., Miyakawa, S., Nakagawa, A., Yamaguchi, J.,
             and H. Ashida, "NAT444 with ISP Shared Address",
             draft-shirasaki-nat444-isp-shared-addr-02 (work in
             progress).





Xu, et al.            Expires February 24, 2011              [Page 11]


Internet-Draft     NAT State Synchronization Using SCSP     August 2010

   [DS-LITE] Durand, A., Droms, R., Woodyatt, J., and Lee, Y., "Dual-
             stack lite broadband deployments post IPv4 exhaustion",
             draft-ietf-softwire-dual-stack-lite-06 (work in progress),
             Auguest 2010.

   [NAT64] Bagnulo, M., Matthews, P., and I. Beijnum, "Stateful
             NAT64: Network Address and Protocol Translation from IPv6
             Clients to IPv4 Servers", draft-ietf-behave-v6v4-xlate-
             stateful-12 (work in progress), July 2010.

   [NAT-STANDBY] Xu, X., Boucadair, M., Lee, Y., and Chen, G.,
             "Redundancy and Load Balancing Framework for Stateful
             Network Address Translators (NAT)", draft-xu-behave-
             stateful-nat-standby-04 (work in progress), Auguest 2010.

Authors' Addresses

   Dean Cheng
   Huawei Technologies,
   2330 Central Expressway, CA 95050,USA
   Phone: +1 408 330 4754
   Email: Chengd@huawei.com


   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


   Joel M. Halpern
   Redback, Ericsson,
   P. O. Box 6049
   Leesburg, VA 20178 USA
   Phone: 703-371-3043
   Email: Joel.Halpern@ericsson.com


   Mohamed Boucadair
   France Telecom
   3, av Francois Chateau
   Rennes  35000
   France
   Email: mohamed.boucadair@orange-ftgroup.com




Xu, et al.            Expires February 24, 2011              [Page 12]