[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]
Versions: 00 01 02 03 04 05 06
Network working group X. Xu
Internet Draft Huawei
Category: BCP M. Boucadair
Expires: February 2011 France Telecom
Y. Lee
Comcast
G. Chen
China Mobile
August 24, 2010
Redundancy and Load Balancing Framework for Stateful Network Address
Translators (NAT)
draft-xu-behave-stateful-nat-standby-04
Abstract
This document defines a framework for ensuring redundancy and/or
load balancing for stateful Network Address Translators (NAT),
including NAT44, NAT64 and NAT46.
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.
Xu, et al. Expires Feburary 24, 2011 [Page 1]
Internet-Draft Redundancy and Load Balancing August 2010
Framework for Stateful NAT
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
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with
respect to this document.
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. Reference Architecture.......................................5
4. Redundancy Mechanisms........................................6
4.1. Cold Standby Mechanism..................................7
4.2. Hot Standby Mechanism...................................9
5. Load Balancing Mechanisms...................................10
6. Election Protocol Considerations............................11
7. State Synchronization Protocol Considerations...............12
8. Security Considerations.....................................12
9. IANA Considerations.........................................12
10. Acknowledgments............................................12
11. References.................................................12
11.1. Normative References..................................12
11.2. Informative References................................12
Authors' Addresses.............................................14
Xu, et al. Expires September 24, 2011 [Page 2]
Internet-Draft Redundancy and Load Balancing August 2010
Framework for Stateful NAT
1. Introduction
Network Address Translation (NAT) has been used as an efficient way
to share the same IPv4 address among several hosts. Recently, due to
IPv4 address shortage, several proposals have been elaborated to
rely on Carrier Grade NAT (CGN) (e.g., [NAT444], [DS-Lite] and
[NAT64]). In such models, CGN function (which MAY be embedded in a
router or be deployed in standalone devices) is deployed within
large-scale networks, such as ISP networks or enterprise ones, where
a large number of customers are located. These customers within a
network which is served by a single CGN device MAY experience
service degradation due to the presence of the single point of
failure. Therefore, redundancy and/or load-balancing capabilities of
the CGN devices are strongly desired in order to deliver highly
available services to customers. Failure detection and repair time
MUST be therefore shortened.
This document describes a framework of redundancy and/or load
balancing for stateful NAT including: NAT44 including DS-lite, NAT64
and NAT46.
Unless otherwise mentioned, NAT and CGN terms throughout this
document, pertain to stateful NAT and stateful CGN. Stateless NAT is
out of the scope of this memo. Except dealing with the exceptional
failures (e.g., power outage, OS crash-down or link failure, etc.),
the redundancy mechanism described in this document can also be used
for planned maintenance operations (i.e., graceful shutdown of the
Primary NAT due to maintenance needs).
The main purpose of this memo is analyzing means to ensure high
availability and load balancing in environments where carrier grade
NAT44, NAT64 and NAT46 are deployed. Some engineering
recommendations are provided for the selection of the IPv6 prefix to
build IPv4-Embedded IPv6 addresses [Format] and the routing
configuration.
2. Terminology
This memo makes use of the terms defined in [RFC2663]. Below are
provided terms specific to this document:
- CGN (Carrier Grade NAT):
a NAT device placed within a large-scale network (e.g., ISP
network, enterprise network, or campus network). These devices
Xu, et al. Expires September 24, 2011 [Page 3]
Internet-Draft Redundancy and Load Balancing August 2010
Framework for Stateful NAT
MAY be placed at the boundary between the large-scale private
network and the public Internet, between a private network and
a large-scale public network or between two heterogeneous (i.e.,
IPv4 and IPv6) IP realms.
- Prefix64:
an IPv6 prefix used for synthesizing IPv6 addresses for the
IPv4 hosts. See [Format] for more details.
- CGN internal address realm (internal realm for short):
a realm where the communication initiators (e.g., a client in
the context of client/server application) are located. For
NAT44, the internal realm refers to the private networks, as
opposed to the IPv4 Internet. For NAT64, the internal realm
means IPv6 network or IPv6 Internet. For NAT46, 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. In the context of DS-Lite architecture, the
internal address realm is assumed to be private IPv4 addresses
even if the transport mode used to convey exchanged traffic is
IPv6. A DS-Lite CGN device (a.k.a., Address Family Transition
Router element (AFTR)) is a special NAT44 device which allows
overlapping IPv4 private addresses and requires IPv6
capabilities and IPv6-specific information to perform its NAT
operation. Details can be found in [DS-Lite].
- CGN 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 NAT44, the
external realm refers to the IPv4 Internet. For NAT64, the
external realm means the IPv4 Internet or IPv4 network. For
NAT46, 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 to
represent the external hosts in the internal realm. Note that
this address pool is specific to NAT46 and NAT64. For NAT46,
the CGN will allocate one internal address (which is an IPv4
Xu, et al. Expires September 24, 2011 [Page 4]
Internet-Draft Redundancy and Load Balancing August 2010
Framework for Stateful NAT
address) from the pool to an external IPv6 host and map the
external IPv6 host's IPv6 address to this IPv4 address. For
NAT64, the CGN internal address pool is the Prefix64 [Format].
This Prefix64 is used for synthesizing internal IPv6 addresses
to represent external IPv4 hosts in the internal realm.
- External address pool:
an address pool used by the CGN for assigning external
addresses to the internal hosts. For NAT44 and NAT64, the
external address pool contains a set of public IPv4 addresses.
For NAT46, the external IPv6 address pool is the Prefix64. The
Prefix64 is used by the CGN for synthesizing the external IPv6
addresses to represent internal IPv4 hosts in the external
realm.
- CPE (Customer Premises Equipment):
a device which is used to interconnect the customer premise
with the service provider's network.
3. Reference Architecture
In a typical operational scenario, as illustrated in Figure 1, two
NAT devices are deployed for redundancy and/or load balancing
purposes. Hence, we describe the corresponding mechanisms based on
this scenario. Note that these mechanisms are also suitable in the
scenarios in which more than two NAT devices are used.
+-------------------------+ +-----------------------+
| | | |
| +-+-----+-+ |
| | NAT-A | |
+----+-------------+ +-+-----+-+ +-------------+ |
| Internal Host | | | |External Host| |
+----+-------------+ | | +-------------+ |
| +-+-----+-+ |
| | NAT-B | |
| Internal realm +-+-----+-+ External realm |
| | | |
+-------------------------+ +-----------------------+
Figure 1. General Scenario of Dual NAT Routers
The redundancy and load-balancing mechanisms for NAT44, NAT46 and
NAT64 are almost identical. In all cases, the NAT device or the
Xu, et al. Expires September 24, 2011 [Page 5]
Internet-Draft Redundancy and Load Balancing August 2010
Framework for Stateful NAT
immediate router of the NAT device announces the reachability of the
NAT device to the external realm. The slight difference is the NAT
reachability information. For example, NAT64 announces an IPv6 route
for the Prefix64; NAT44 announces an IPv4 default route; DS-Lite
AFTR announces an IPv6 route pointing to itself; and NAT46 announces
a route for its internal address pool. This difference does not
affect the general redundancy and load-balancing mechanisms, so the
mechanisms described in this memo can be applied to all NAT devices.
4. Redundancy Mechanisms
The fundamental principle of NAT redundancy is to make two or more
NAT devices function as a redundancy group, and select one as the
Primary NAT and the other(s) as the Backup NAT through a dedicated
election procedure (see Section 6) or manual configuration. In the
nominal regime, datagrams exchanged between hosts in the internal
realm and those in the external realm are handled by the Primary NAT.
Once the Primary NAT is out of service (means to detect and to
notify this failure to the redundancy group SHOULD be activated),
the Backup NAT with the highest priority (if several Backup NAT
devices are deployed) takes over and provides the NAT services to
the internal hosts. This Backup NAT is then identified as new
Primary NAT. Once the former Primary NAT became operational, it
could either preempt the role of Primary NAT or stay as a candidate
in the redundancy group. This is part of administrative policies and
out of scope of this memo.
To ensure a coherent behavior when NAT device fails, this document
assumes that both Primary and Backup NAT devices are managed by the
same administrative domain. Thus, consistent configuration policies
SHOULD be enforced in all devices. Note that the election process
MUST be deterministic and does not lead to fuzzy situation where two
or more NAT devices will become Primary NAT. Moreover, the failover
MUST be quick to ensure service continuity.
Two redundancy mechanisms are described hereafter: the cold or the
hot standby mechanism:
The Cold Standby Mechanism is just to keep the NAT failover
transparent to the internal hosts. The NAT states are not
replicated from the Primary NAT to the Backup NAT. When the
Primary NAT fails, all the existing established sessions will
be flushed out. The internal hosts are required to re-establish
sessions to the external hosts;
Xu, et al. Expires September 24, 2011 [Page 6]
Internet-Draft Redundancy and Load Balancing August 2010
Framework for Stateful NAT
The Hot Standby Mechanism is to maintain established sessions
while failover happens. NAT states are replicated from the
Primary NAT to the Backup NAT. When the Primary NAT fails, the
Backup NAT will take over all the existing established sessions.
The internal hosts are not required to re-establish sessions to
the external hosts.
The following sub-sections provide more information about these two
modes.
4.1. Cold Standby Mechanism
4.1.1 Internal Realm
For Cold Standby Mechanism, the internal addresses used to represent
the external hosts in the internal realm SHOULD be retained after
the NAT failover. The following assesses how this requirement is met
in each NAT flavor:
For NAT44 and DS-Lite, the external hosts' internal addresses
(i.e., the addresses used to represent the external hosts in
the internal realm) are unchanged (i.e., not NAT-ed). Therefore,
the above requirement is met without additional work.
For NAT64, the NAT devices belonging to a redundancy group
SHOULD be configured with an identical Prefix64. Since the
NAT64 uses stateless address translation for the external hosts,
using the same Prefix64 in the Backup NAT can guarantee the
internal hosts to see the same internal addresses for the
external hosts.
For NAT46, NAT devices in a redundancy group SHOULD be
configured with an identical IPv4 address pool. A subset of
translation state information SHOULD be synchronized among
these NAT devices through a dedicated state synchronization
protocol [NAT-Sync]. This translation state ensures that the
Backup NAT, once taking over as a Primary NAT, will assign the
same IPv4 addresses to the external IPv6 hosts for the internal
IPv4 hosts.
4.1.2 External Realm
Each NAT device in a NAT redundancy group is configured with a
different external address pool. A route to that external pool is
then announced into the external realm by the NAT device or the NAT
immediate router.
Xu, et al. Expires September 24, 2011 [Page 7]
Internet-Draft Redundancy and Load Balancing August 2010
Framework for Stateful NAT
For NAT44, DS-Lite and NAT64: NAT devices are configured with
different external IPv4 address pools. These address pools are
not overlapped. Otherwise, when the Primary NAT fails and the
Backup NAT takes over the Primary NAT, a NAT collision MAY
happen. For example, assuming a Primary NAT NAT-ed internal
host Host-A to IPv4-A. IPv4-A is an address belonging to the
external address pool. If the Backup NAT (i.e., the newly
elected Primary NAT) was configured with the same pool, the
Backup NAT MAY assign the same IPv4-A to another internal host
Host-B. This might cause confusion to the internal hosts. In
addition, by using different external address pools on each NAT
device, incoming datagrams of a given session from the external
hosts are ensured to always traverse the same NAT device even
after NAT failover happens.
For NAT46, the issue occurred in NAT44 and NAT64 cases will
not happen when Primary and Backup NAT use the same external
IPv6 address pool (i.e., the Prefix64). The NAT46 relies on
stateless address translation for the internal hosts. Hence the
external hosts can use any NAT46 to reach the internal hosts.
In Cold Standby mechanism, the Primary and Backup NAT MAY use
different Prefix64s. In contrast, the Primary and Backup NAT in
Hot Standby mechanism MUST use an identical Prefix64.
4.1.3 NAT Reachability Announcement
In order to force IP datagrams from the internal realm to always
traverse the Primary NAT to the external realm, the Primary NAT
SHOULD announce into the internal realm a route towards the external
realm.
For NAT44, the Primary NAT announces an IPv4 default route
into the internal realm.
For DS-Lite, the Primary NAT announces a host route into the
internal realm.
For NAT64, the Primary NAT announces a route for the Prefix64
into the internal realm.
For NAT46, the Primary NAT announces a route for the internal
address pool into the internal realm (If the internal address
pool can be aggregated to one prefix).
Xu, et al. Expires September 24, 2011 [Page 8]
Internet-Draft Redundancy and Load Balancing August 2010
Framework for Stateful NAT
The Primary NAT SHOULD attempt to withdraw its previously announced
route when it ceases the Primary role due to some reason, e.g., it
loses the connectivity to the external realm.
When the Primary NAT fails and the Backup NAT takes over, datagrams
from the internal hosts destined for the external realm SHOULD pass
through the Backup NAT. Hence, if the Primary NAT and the Backup one
are specified manually, the Backup NAT (or associated router) SHOULD
announce into the internal realm the same route towards the external
realm as that announced by the Primary NAT so as to prepare for the
failover, but the cost of this route MUST be set a much higher value
than that of the route announced by the Primary NAT. Alternatively,
the Primary NAT announces several more specific routes into the
internal realm while the Backup NAT announces an aggregate route.
Taken the NAT46 as an example, assuming the internal address pool is
10.0.0.0/8, the Primary NAT announces two more specific routes to
10.0.0.0/9 and 10.128.0.0/9 respectively while the Backup NAT
announces an aggregate route to 10.0.0.0/8. In case the Primary NAT
and the Backup NAT are automatically elected through a dedicated
election process, the Backup NAT would be elected as a new Primary
NAT once the old Primary one fails, so it is not necessary for the
Backup NAT to make the above route announcements until it is elected
as a new Primary NAT.
In order for the external hosts to route through the NAT to the
internal hosts, the Primary and Backup NAT SHOULD announce a route
of its own external address pool into the external realm,
respectively..
4.2. Hot Standby Mechanism
4.2.1 Internal Realm
This is identical to Section 4.1.1.
4.2.2 External Realm
To preserve the established sessions during the failover, in
addition to keeping the internal addresses for the external hosts
unchanged, the external addresses for the internal hosts MUST also
be preserved. To preserve the external address of the internal host
after NAT-ed, the NAT devices in a redundancy group MUST use an
identical external address pool. In addition, they MUST assign the
same external address (or address/port pair) to a given internal
host.
Xu, et al. Expires September 24, 2011 [Page 9]
Internet-Draft Redundancy and Load Balancing August 2010
Framework for Stateful NAT
For NAT46, the Primary NAT and Backup NAT MUST use an
identical Prefix64.
For NAT44, DS-Lite and NAT64, the NAT devices in a redundancy
group MUST use the same external address pool and the
translation states on the Primary NAT device MUST be
synchronized to the Backup NAT(s) in a timely fashion.
4.2.3 NAT Reachability Announcement
In order to force IP datagrams between the internal realm and the
external realm always traverse the Primary NAT, the Primary NAT (or
its associated router) SHOULD announce into the internal realm a
route towards the external realm and announces into the external
realm a route towards the external address pool. Once the
connectivity to either the external realm or the internal realm is
lost, the Primary NAT device itself or a third party SHOULD attempt
to withdraw the above routes. If the Primary NAT and the Backup NAT
are specified manually, the Backup NAT device (or its associated
router) SHOULD also announce those routes, but with higher enough
cost or larger granularity, so as to prepare for the failover. When
the Primary NAT fails, the datagrams towards the external realm will
pass through the Backup NAT device. In case the Primary NAT and the
Backup are automatically elected through a dedicated election
procedure, the Backup NAT would be elected as a new Primary NAT when
the old Primary NAT device fails. Consequently, it is not necessary
for the Backup NAT to make the above route announcement until it is
elected as a new Primary NAT.
5. Load Balancing Mechanisms
Based on the above redundancy mechanisms, one can further realize
load balancing among a group of NAT devices. The basic idea is to
create two redundancy groups (e.g., Group A and Group B) on these
NAT devices, make one device as the Primary NAT for Group A and the
Backup NAT for Group B, while make the other as the Primary NAT for
Group B and the Backup NAT for Group A. Taking NAT64 as an example,
NAT devices are configured with two prefix64s (e.g., Prefix64-A and
Prefix64-B) corresponding to the two redundancy groups, and one
device is designated as the Primary NAT for Group A and the Backup
NAT for Group B, while the other as the Backup NAT for Group A and
the Primary NAT for Group B. Therefore, the IPv6 datagrams towards
the IPv4 external realm are balanced among these NAT devices
according to their destination addresses with different Prefix64s.
Xu, et al. Expires September 24, 2011 [Page 10]
Internet-Draft Redundancy and Load Balancing August 2010
Framework for Stateful NAT
For load balancing together with cold standby, each NAT device could
either use the same external address pool or different external
address pools corresponding to these redundancy groups. However, in
the case of NAT64, in order to easily determine which Prefix64
SHOULD be used for synthesizing IPv6 address of a given IPv4 host in
the return direction, it would be better to assign different address
pools for different redundancy groups. In this way, the Prefix64 can
be easily determined according to the destination IPv4 address in
the return packets sent from the IPv4 host. Besides, the external
address pools on one NAT device SHOULD NOT have any overlap with
those of the other NAT device. Otherwise, the same address or
address/port pair could be assigned occasionally to different
internal hosts. In contrast, for load balancing together with 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 device.
6. Election Protocol Considerations
An election process and associated protocol(s) is used to
automatically elect one NAT device among a NAT redundancy group as
the Primary NAT and the others as Backup NATs. Once the Primary NAT
fails, the Backup NAT with the highest priority SHOULD take over the
Primary NAT role after a short delay. The election protocol is also
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 device is not qualified to be the
Primary NAT 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 external address pool.
As an implementation example, VRRP [RFC2338] can be used as the
automatic election protocol. In addition, an interface tracking
mechanism can also be used to adjust the priority to influence the
election results.
If two NAT devices are directly connected via an Ethernet network,
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 devices.
For example, to 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 on those interfaces is not
supported, the following trick to realize the same goal, but at a
cost of consuming two physical interfaces on each NAT router: create
a VPLS instance among a set of NAT devices, and on each of them one
Xu, et al. Expires September 24, 2011 [Page 11]
Internet-Draft Redundancy and Load Balancing August 2010
Framework for Stateful NAT
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 extend
VRRP so that VRRP neighbors can be specified manually and VRRP
messages can be exchanged directly among VRRP neighbors in unicast.
VRRP is only an implementation example of the election process.
Other protocols MAY be used to manage the roles of Primary and
Backup.
7. State Synchronization Protocol Considerations
[NAT-Sync] defines a candidate solution to NAT state synchronization
by using Server Cache Synchronization Protocol (SCSP) [RFC2334]. For
more information about the proposed solution, the reader is invited
to refer to [NAT-Sync].
8. Security Considerations
TBD.
9. IANA Considerations
There are no IANA considerations for this document.
10. Acknowledgments
The author would like to thank Dan Wing and Dave Thaler for their
insightful comments and reviews, and thank Dacheng Zhang and Xuewei
Wang for their valuable editorial reviews.
11. References
11.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
11.2. Informative References
[RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network
Address NAT (Traditional NAT)", RFC 3022, January 2001.
Xu, et al. Expires September 24, 2011 [Page 12]
Internet-Draft Redundancy and Load Balancing August 2010
Framework for Stateful NAT
[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.
[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, "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.
[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), September 2009.
[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.
Xu, et al. Expires September 24, 2011 [Page 13]
Internet-Draft Redundancy and Load Balancing August 2010
Framework for Stateful NAT
[Format] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and Li,
X., "Framework for IPv4/IPv6 Translation", draft-ietf-
behave-address-format-10.txt (work in progress), August,
2010.
[Framework] Baker, F., Li,X., Bao,C., and Yin,K., "Framework for
IPv4/IPv6 Translation", draft-ietf-behave-v6v4-framework-
07 (work in progress), February, 2010.
[NAT-Sync] Chen, D., Xu, X., Halpern, J., and Boucadair, M., "NAT
State Synchronization Using SCSP", draft-xu-behave-nat-
state-sync-02 (work in progress), August, 2010.
Authors' Addresses
Xiaohu Xu
Huawei Technologies,
No.3 Xinxi Rd., Shang-Di Information Industry Base,
Hai-Dian District, Beijing 100085
P.R. China
Email: xuxh@huawei.com
Mohamed Boucadair
France Telecom
3, av Francois Chateau
Rennes 35000
France
Email: mohamed.boucadair@orange-ftgroup.com
Yiu Lee
Comcast
1, Comcast center
Philadelphia, PA 19103
USA
Gang Chen
China Mobile
53A,Xibianmennei Ave.
Beijing 100053
P.R.China
Email: phdgang@gmail.com
Xu, et al. Expires September 24, 2011 [Page 13]
Html markup produced by rfcmarkup 1.129c, available from
https://tools.ietf.org/tools/rfcmarkup/