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]