Network Working Group G. Chen
Internet-Draft H. Deng
Intended status: Experimental B. Zhou
Expires: January 7, 2010 China Mobile
M. Xu
L. Song
Y. Cui
Tsinghua University
July 6, 2009
Reliable and Scalable NAT mechanism (RS-NAT) based on BGP for IPv4/6
Transition
draft-chen-behave-rsnat-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 January 7, 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.
Chen, et al. Expires January 7, 2010 [Page 1]
Internet-Draft RS-NAT July 2009
Abstract
For the rapid exhaustion of IPv4 address pool against the slow
development of IPv6, IPv4/6 coexistence/transition proved to be a
long period. In the IPv4/6 transition process, there are many NAT-
like technologies existing in the internet. However the NAT boxes
such as IPv4 NAT, IPv4/6 NAT are so poor in their reliability and
scalability, which put a severe threat on the development of IPv4/6
Transition. This document defines a reliable and scalable NAT(RS-
NAT)mechanism to solve the problem.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. RS-NAT Overview . . . . . . . . . . . . . . . . . . . . . . . 4
3. RS-NAT Box . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Load Balancing Mechanisms . . . . . . . . . . . . . . . . . . 6
4.1. IPv6-IPv4 scenario . . . . . . . . . . . . . . . . . . . . 6
4.2. IPv4-IPv6 scenario . . . . . . . . . . . . . . . . . . . . 7
5. Redundancy Mechanisms . . . . . . . . . . . . . . . . . . . . 9
5.1. Address mapping Attribute . . . . . . . . . . . . . . . . 9
5.2. Performance consideration . . . . . . . . . . . . . . . . 10
6. Security Considerations . . . . . . . . . . . . . . . . . . . 11
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
9.1. Normative References . . . . . . . . . . . . . . . . . . . 14
9.2. Informative References . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16
Chen, et al. Expires January 7, 2010 [Page 2]
Internet-Draft RS-NAT July 2009
1. Introduction
For the rapid exhaustion of IPv4 address pool against the slow
development of IPv6, IPv4/6 coexistence/transition proved to be a
long period. In the IPv4/6 transition process there are obviously
two trends: one is the supporter of IPv6, who proposed many
transition mechanisms such as NAT-PT , NAT64. The other is reluctant
to use IPv6 because of the high cost of upgrade they network and some
applications and want to use NAT444, DS-Lite to delay the exhaustion
of IPv4. No matter which side will win the future, the NAT-like
function is a key point in the coexistence/transition period.
However much of the NAT-like functions are stateful, which maintain
the state of address mapping for network translation or ALG function.
The stateful boxes in the network exert high threat on reliability
and scalability when the network becomes huge. For example the box
will be single point of failure in the large scaled Network.
Although some advices are proposed such as mentioned in NAT64 using
multi-box, the static configuration and localized mapping information
in each box are not able to accommodate the dynamic internet
environment.
In this document, we proposed a reliable and scalable NAT mechanism
to overcome the stateful NAT problem mentioned above, which include
IPv4 NAT and IPv4/6 NAT. Note that the stateless NAT mechanism
IVI[I-D.baker-behave-ivi], and its limitation is out the scope of
this document.
Chen, et al. Expires January 7, 2010 [Page 3]
Internet-Draft RS-NAT July 2009
2. RS-NAT Overview
In the topology shown in figure 1, there are two main parts of
network: the User Network and Service Network. User Network is the
realm where the users initiate the communication with servers. The
Service Network is the realm where the public service server located.
In addition there are some RS-NAT boxes which act as bridges between
the networks.
____________ _______________
/. .. .. .. .\ +--------+ /. .. .. .. .. .\
| |--|RS-NAT A|--| |
| | +--------+ | |
|User Network| | |Service Network|
| | +--------+ | |
|. .. .. .. .|--|RS-NAT B|--|. .. .. .. .. .|
\____________/ +--------+ \_______________/
Figure 1: General Topology of RS-NAT framework
The User Network and Service Network can be IPv4,IPv6 or Dual-stacks.
As a result there are several communication scenarios learned from
the general topology using the general form IPvx-IPvy, which means
users with IPvx protocol initiate connections to servers with IPvy
protocol. These communication scenarios are (private)IPv4-IPv4,
IPv4-IPv6, IPv6-IPv4, and IPv6-IPv6. VRRP[RFC3768] is perfect for
IPv4-IPv4 scenarios and there is no need to use NAT for IPv6-IPv6.
So in this document we mainly focus on IPv4-IPv6/IPv6-IPv4 scenarios.
The User Network and Service Network are logical concepts, which may
be composed of many small networks in one AS or several Ases. For
example the User Network shown in Figure 1 may consist of several
IPv4 metropolitan area networks in one network provider.The Service
Network may be composed of IPv6 islands connected directly, through
tunnels or IPv6 transit-core such as CNGI-CERNET2 in China. The
metropolitan area networks in User Network may connect to Service
Network individually through RS-NAT boxes which may be located at
different cities. Obviously these sub-networks is multi-homed at
least with two access links. Although the problem of multi-homing is
beyond the scope of this document, it is worth explaining the detail
of the topology.
Note that the definition of User Network and Service Network are
defined according to one communication. They are not strict because
an end user can regarded as both initiator and server from different
views.
Chen, et al. Expires January 7, 2010 [Page 4]
Internet-Draft RS-NAT July 2009
3. RS-NAT Box
The following sections will discuss the requirement of RS-NAT Box and
its basic functions.
In order to achieve the role of bridge between the two networks in
the scenarios, which are depicted in sections 3, the RS-NAT box
should have three basic functions: the support of IPv4/6 dual-stack,
router and IPv4/6 address translator.
In the IPv6-IPv4 scenario RS-NAT router advertise the prefix64
[I-D.miyata-behave-prefix64] routing information to User Network, and
advertise the prefix info of static IPv4 address pool to Service
Network. In this scenario DNS64 [I-D.bagnulo-behave-dns64] is
employed to dispatch the prefix64 for each DNS request, which will be
discussed in section 5. In the IPv4-IPv6 scenario RS-NAT router
advertise its own IPv6 prefix routing information to Service Network,
and send the prefix info of static IPv4 address pool to User Network.
In this scenario DNS ALG mentioned in NAT-PT will be modified to
support the separation of the data plane and control plane, which
will be discussed in section 5.
As an IP protocol translator the mapping mechanism in RS-NAT is also
an important part. The address mapping information is useful not
only for the IP head translation, but essential for some application
that embed network-layer addresses as well, such as FTP, SIP etc.
Chen, et al. Expires January 7, 2010 [Page 5]
Internet-Draft RS-NAT July 2009
4. Load Balancing Mechanisms
Sections 3 and 4 have already depicted the framework of RS-NAT and
the key role: RS-NAT box. This section will show how the RS-NAT run
and balance the traffic among these RS-NAT boxes.
4.1. IPv6-IPv4 scenario
Figure 2 illustrates the connection setup in IPv6-IPv4 scenario. The
connection setup follows two steps:
1) User sends DNS query to DNS64 and get the DNS reply with a IPv4-
embeded IPv6 addresses in the form of Prefix64::IPv4 adress;
2) User sends the packet to the IPv4-embeded IPv6 addresses. The
different IPv6 prefix will lead the packet to different RS-NAT
routers, which is achieved by the RS-NAT routing function.
The Control Plane
....................
+-----+
.........|DNS64|
. +-----+
+----+. +------+ +------+
|User| --------- |RS-NAT|---------|server|
+----+\ +------+ /+------+
\ +------+ /
---------|RS-NAT|-------
+------+
--------------------
The Data Plane
Figure 2: IPv6-IPv4 Connection Setup
As mentioned previously RS-NAT routers run BGP and keep BGP neighbor
information with each other. Each RS-NAT router will maintain the
IPv6 prefix pool just as DNS64 does and they will use a Prefix-
Assignment Algorithm to decide individually which part of prefix64
they are in charge of. The Prefix-Assignment Algorism follows the
simple idea that all RS-NAT routers share the prefix almost evenly
based on the BGP neighbor information.
For example there is 2^8 2001::/24 in prefix64 pool 2001::/16 and
there are 2 RS-NAT routers which are sorted according to the size of
IP address. The Assignment plan is that prefixes form 2001:0000::/24
to 2001:7f00::/24 will be assigned to the router with larger IP
address, and the prefixes from 2001:8000::/24 to 2001:ff00::/24 is in
Chen, et al. Expires January 7, 2010 [Page 6]
Internet-Draft RS-NAT July 2009
the charge of the other router. If there are more RS-NAT routers,
these prefixes can also easy assigned to them.
In order to balance the traffic among these RS-NAT routers, each
router should advertise the route of its converged prefix64 to User
Network. Note that for the Redundancy consideration each router can
advertise the routes of other part of prefix64 with higher cost or
larger granularity in order that when other RS-NAT routers fail for
some reason, the alive can work immediately.
Note that once RS-NAT routers are failed or new RS-NAT routers are
configured to join in, the routing for load balance can be
automatically configured by RS-NAT routers by themselves. Prefix-
Assignment Algorithm will be triggered in each RS-NAT router to
recompute the router prefix. BGP KEEPALVE and OPEN messages are used
to achieve that trigger which will be explored in the next version of
this document .
4.2. IPv4-IPv6 scenario
The load balancing mechanism in IPv4-IPv6 is similar to the one in
IPv6-IPv4 in that the IPv4 address pool should shared by RS-NAT
routers and each RS-NAT router is responsible to advertise the route
of their IPv4 address pool, which is similar to the routing procedure
of RS-NAT routers in IPv6-IPv4. The IPv4-IPv6 Connection Setup is
shown in figure 3.
The Control Plane
.....................
+----+ +-------+ +----+
|DNS4|....|DNS ALG|......|DNS6|
+----+ +---|---+ +----+
+----+. +--|---+ +------+
|User| ---------- |RS-NAT| --------|server|
+----+\ +--|---+ /+------+
\ +--|---+ /
--------- |RS-NAT| ------
+------+
---------------------
The Date plane
Figure 3: IPv4-IPv6 Connection Setup
The differences between the two scenarios are in two fold:
Chen, et al. Expires January 7, 2010 [Page 7]
Internet-Draft RS-NAT July 2009
o The control plane: In IPv6-IPv4 it is the DNS64 that synchronize
the IPv6 and IPv4 address for IPv4 hosts, while in IPv4-IPv6 a DNS
ALG server monitors the DNS request and reply forming the mapping
of IPv4/6 address.
o Address mapping advertisement: For the load balancing reason,DNS
ALG server is not designed for traffic translation and forwarding,
which part is separated to RS-NAT routers. As a result the DNS
ALG server should send the mapping info to RS-NAT routers using
new BGP attribute which will be defined in section 6.
Note that if the scenario is the mixture of the two, RS-NAT can work
well with proper address configuration.
Chen, et al. Expires January 7, 2010 [Page 8]
Internet-Draft RS-NAT July 2009
5. Redundancy Mechanisms
If there exits multi boxes between the two edge of network, problems
will arise when some boxes are not stable or failed. The problems
are mainly in two aspects. The first problem is in routing aspect:
when one box fails, there is no other valid routes to the
destination. The second is in address mapping aspect: when one box
fails, the address mapping information in the box is lost causing the
flows breaking up and reconnection.
The first problem is solved in section 4 in that the routing
mechanism makes sure that the taffic will find a way out through
another RS-NAT router by setting the different route cost or
preference. In this section we will define a BGP attribute that one
RS-NAT can advertise the local address mapping to other neighbors
which guarantees the redundancy of mapping info. With that
redundancy address mapping information RS-NAT routers are able to
translate the new traffic
5.1. Address mapping Attribute
Address mapping attribute is an optional transitive attribute that is
composed of a set of TLVs. The type code of the attribute is to be
assigned by IANA. Each TLV contains information corresponding to a
particular tunnel technology. The TLV is structured as follows:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| mapping Type (2 Octets) | Length (2 Octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Value |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
apping Type (2 octets): It identifies the type of the mapping
information being transmitted. This document defines the following
types:
- IPv4-IPv4: mapping Type = 1
- IPv4-IPv6/IPv6-IPv4: mapping Type = 2
- IPv6-IPv6: mapping Type=3
Unknown types are to be ignored and skipped upon receipt.
Chen, et al. Expires January 7, 2010 [Page 9]
Internet-Draft RS-NAT July 2009
Length (2 octets): the total number of octets of the Value field.
Value (variable): The value is composed of the address mapping
information. If mapping type is 2, the value contains an IPv4/6
address mapping just simply structured as follows:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 address (4 Octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| IPv6 address (16 Octets) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
5.2. Performance consideration
As the mapping information is tremendous and dynamic. The
performance of RS-NAT is an important issue. BGP reflector can be
utilized to reduce the BGP update massage. If reflector is deployed,
new mechanism should guarantee each RS-NAT routers knowing the number
of routers.In addition some optimization of RS-NAT and possible
modifications of BGP will be explored in the next version of this
document.
Note that RS-NAT routers are located on the edge of network and they
may not connect directly. BGP has its nature advantage to do
signaling among edge routers over some intra-domain protocol.
Chen, et al. Expires January 7, 2010 [Page 10]
Internet-Draft RS-NAT July 2009
6. Security Considerations
TBD
Chen, et al. Expires January 7, 2010 [Page 11]
Internet-Draft RS-NAT July 2009
7. IANA Considerations
TBD
Chen, et al. Expires January 7, 2010 [Page 12]
Internet-Draft RS-NAT July 2009
8. Acknowledgments
TBD
Chen, et al. Expires January 7, 2010 [Page 13]
Internet-Draft RS-NAT July 2009
9. References
9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2694] Srisuresh, P., Tsirtsis, G., Akkiraju, P., and A.
Heffernan, "DNS extensions to Network Address Translators
(DNS_ALG)", RFC 2694, September 1999.
[RFC2766] Tsirtsis, G. and P. Srisuresh, "Network Address
Translation - Protocol Translation (NAT-PT)", RFC 2766,
February 2000.
[RFC2893] Gilligan, R. and E. Nordmark, "Transition Mechanisms for
IPv6 Hosts and Routers", RFC 2893, August 2000.
[RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network
Address Translator (Traditional NAT)", RFC 3022,
January 2001.
[RFC3768] Hinden, R., "Virtual Router Redundancy Protocol (VRRP)",
RFC 3768, April 2004.
[RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway
Protocol 4 (BGP-4)", RFC 4271, January 2006.
[RFC4966] Aoun, C. and E. Davies, "Reasons to Move the Network
Address Translator - Protocol Translator (NAT-PT) to
Historic Status", RFC 4966, July 2007.
9.2. Informative References
[I-D.bagnulo-behave-dns64]
Bagnulo, M., Sullivan, A., Matthews, P., Beijnum, I., and
M. Endo, "DNS64: DNS extensions for Network Address
Translation from IPv6 Clients to IPv4 Servers",
draft-bagnulo-behave-dns64-02 (work in progress),
March 2009.
[I-D.bagnulo-behave-nat64]
Bagnulo, M., Matthews, P., and I. Beijnum, "NAT64: Network
Address and Protocol Translation from IPv6 Clients to IPv4
Servers", draft-bagnulo-behave-nat64-03 (work in
progress), March 2009.
[I-D.baker-behave-ivi]
Chen, et al. Expires January 7, 2010 [Page 14]
Internet-Draft RS-NAT July 2009
Li, X., Bao, C., Baker, F., and K. Yin, "IVI Update to
SIIT and NAT-PT", draft-baker-behave-ivi-01 (work in
progress), September 2008.
[I-D.durand-softwire-dual-stack-lite]
Durand, A., Droms, R., Haberman, B., and J. Woodyatt,
"Dual-stack lite broadband deployments post IPv4
exhaustion", draft-durand-softwire-dual-stack-lite-01
(work in progress), November 2008.
[I-D.miyata-behave-prefix64]
Miyata, H. and M. Bagnulo, "PREFIX64 Comparison",
draft-miyata-behave-prefix64-02 (work in progress),
March 2009.
[I-D.shirasaki-nat444-isp-shared-addr]
Shirasaki, Y., Miyakawa, S., Nakagawa, A., Yamaguchi, J.,
and H. Ashida, "NAT444 with ISP Shared Address",
draft-shirasaki-nat444-isp-shared-addr-01 (work in
progress), March 2009.
Chen, et al. Expires January 7, 2010 [Page 15]
Internet-Draft RS-NAT July 2009
Authors' Addresses
Gang Chen
China Mobile
53A,Xibianmennei Ave.
Beijing 100053
P.R.China
Phone: +86-13910710674
Email: phdgang@gmail.com
Hui Deng
China Mobile
53A,Xibianmennei Ave.
Beijing 100053
P.R.China
Phone: +86-13910750201
Email: denghui02@gmail.com
Bo Zhou
China Mobile
53A,Xibianmennei Ave.
Beijing 100053
P.R.China
Phone: +86-13811948723
Email: zhouboyj@chinamobile.com
Mingwei Xu
Tsinghua University
Department of Computer Science, Tsinghua University
Beijing 100084
P.R.China
Phone: +86-10-6278-5822
Email: xmw@csnet1.cs.tsinghua.edu.cn
Chen, et al. Expires January 7, 2010 [Page 16]
Internet-Draft RS-NAT July 2009
Linjian Song
Tsinghua University
Department of Computer Science, Tsinghua University
Beijing 100084
P.R.China
Phone: +86-10-6278-5822
Email: songlinjian@csnet1.cs.tsinghua.edu.cn
Yong Cui
Tsinghua University
Department of Computer Science, Tsinghua University
Beijing 100084
P.R.China
Phone: +86-10-6278-5822
Email: cuiyong@tsinghua.edu.cn
Chen, et al. Expires January 7, 2010 [Page 17]