Network working group D. Cheng
Internet Draft X. Xu
Category: Standard Track Huawei
Expires: March 2010 J. Halpern
Ericsson
M. Boucadair
France Telecom
September 19, 2009
NAT State Synchronization Using SCSP
draft-xu-behave-nat-state-sync-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 March 19, 2010.
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, et al. Expires March 19, 2010 [Page 1]
Internet-Draft NAT State Synchronization Using SCSP September 2009
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.....................7
2.2. NAT64 Specific fields in CSA Record.....................8
2.3. NAT46 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. References..................................................11
6.1. Normative References...................................11
6.2. Informative References.................................11
Authors' Addresses.............................................12
Xu, et al. Expires March 19, 2010 [Page 2]
Internet-Draft NAT State Synchronization Using SCSP September 2009
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
carrier's networks. One method for achieving this is to deploy two
or more NAT devices with redundancy, as proposed in [NAT-STANDBY].
When multiple NAT devices are deployed in a hot-standby mode(see
[NAT-STANDBY] for more details), the associated translation states
that are maintained on a primary NAT device must be synchronized to
its 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 a 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 March 19, 2010 [Page 3]
Internet-Draft NAT State Synchronization Using SCSP September 2009
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.
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) should 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 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
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
Xu, et al. Expires March 19, 2010 [Page 4]
Internet-Draft NAT State Synchronization Using SCSP September 2009
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 of 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 and switchover
mechanism 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
TCP state
TCP timestamp
Xu, et al. Expires March 19, 2010 [Page 5]
Internet-Draft NAT State Synchronization Using SCSP September 2009
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) /
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
Xu, et al. Expires March 19, 2010 [Page 6]
Internet-Draft NAT State Synchronization Using SCSP September 2009
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) /
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
Xu, et al. Expires March 19, 2010 [Page 7]
Internet-Draft NAT State Synchronization Using SCSP September 2009
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.
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 |
+ +
| |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2.2. NAT64 Specific fields in CSA Record
This section defined the specific fields in the CSA Record for NAT64.
Xu, et al. Expires March 19, 2010 [Page 8]
Internet-Draft NAT State Synchronization Using SCSP September 2009
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 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 +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Address Mapped from (32 bits)
Xu, et al. Expires March 19, 2010 [Page 9]
Internet-Draft NAT State Synchronization Using SCSP September 2009
The IPv4 address which is dynamically allocated by the NAT46
for the IPv6 host. This address is also call 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 call 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,
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.
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.
Xu, et al. Expires March 19, 2010 [Page 10]
Internet-Draft NAT State Synchronization Using SCSP September 2009
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.
6. References
6.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
6.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-00 (work in
progress), October 2008.
[DS-LITE] Durand, A., "Dual-stack lite broadband deployments post
IPv4 exhaustion", draft-ietf-softwire-dual-stack-lite-01
(work in progress), July 2009.
[NAT64] Bagnulo, M., Matthews, P., and I. Beijnum, "NAT64: Network
Address and Protocol Translation from IPv6 Clients to
IPv4 Servers", draft-ietf-behave-v6v4-xlate-stateful-01
(work in progress), July 2009.
[NAT-STANDBY] Xu, X., "Redundancy and Load Balancing Mechanisms for
Stateful Network Address Translators (NAT)", draft-xu-
behave-stateful-nat-standby-00 (work in progress),
June 2009.
Xu, et al. Expires March 19, 2010 [Page 11]
Internet-Draft NAT State Synchronization Using SCSP September 2009
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 March 19, 2010 [Page 12]