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]