Network Working Group G. Chen
Internet-Draft H. Deng
Intended status: Experimental B. Zhou
Expires: January 14, 2010 China Mobile
M. Xu
L. Song
Y. Cui
Tsinghua University
July 13, 2009
Reliable and Scalable NAT mechanism (RS-NAT) based on BGP for IPv4/6
Transition
draft-chen-behave-rsnat-01
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 14, 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 14, 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 is insufficient in their reliability and
scalability, which might cause a single point of failure in IPv4/6
transition architecture. 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. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
8.1. Normative References . . . . . . . . . . . . . . . . . . . 13
8.2. Informative References . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14
Chen, et al. Expires January 14, 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 order to facilitate the connectivity between IPv4
and IPv6 network, a NAT functionality should be deployed on the edge
of different IP family network.
However most 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 will bring high risks on
reliability and scalability when the network becomes huge. For
example the box will be a single point of failure in a large-scale
network. Although some advices are proposed such as 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 (RS-NAT)
mechanism to overcome the stateful NAT problem mentioned above, which
include IPv4 NAT and IPv4/6 NAT.
Chen, et al. Expires January 14, 2010 [Page 3]
Internet-Draft RS-NAT July 2009
2. RS-NAT Overview
In the topology shown in figure 1, the network can be divided into
two parts: the User Network and Service Network. User Network is the
realm where the users initiate a 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 could be IPv4,IPv6 or Dual-
stacks. As a result there are several communication scenarios could
be deduced from the general topology using the form of 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 suitable
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 several ASes. For example the User Network shown in
Figure 1 may consist of several IPv4 networks belong to diffrent
network providers. The User Network may connect to Service Network
separately through RS-NAT boxes on which BGP [RFC4271] is performed .
Note that the User Network and Service Network are exchangable
because an end user can be regarded as both initiator and server from
different views.
Chen, et al. Expires January 14, 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 is
capable of dual-stack and forwording traffic based on 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 assign the prefix64 for each DNS request, which will be
discussed in section 5. In the IPv4-IPv6 scenario RS-NAT router
advertises its own IPv6 prefix routing information to Service
Network, and sends the prefix info of static IPv4 address pool to
User Network. In this scenario DNS ALG mentioned in NAT-PT[RFC2766]
will be modified to support the separation of the data plane and
control plane, which will be discussed in section 5.
The address mapping modules in RS-NAT 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 14, 2010 [Page 5]
Internet-Draft RS-NAT July 2009
4. Load Balancing Mechanisms
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 which is identical with the prefix DNS64 stores. RS-NAT
will performe a Prefix-Assignment Algorithm to decide individually
which part of prefix64 they are in charge of. The Prefix-Assignment
Algorism follows the new idea that the IPv6 prefix is equally divided
into several portions. And, each of them is assigned to RS-NAT
routers.
For example, there is 2^8 2001::/24 in prefix64 pool of 2001::/16 and
2 RS-NAT routers. The Assignment plan is that prefixes from 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 the charge of the other router. If there are more
Chen, et al. Expires January 14, 2010 [Page 6]
Internet-Draft RS-NAT July 2009
RS-NAT routers, these prefixes can also easy assigned to them
according to the IP address sorting.
In order to balance the traffic among these RS-NAT routers, each
router should advertise the route of its aggregated prefix64 to User
Network. Note that for the Redundancy consideration each router
could advertise overlapped prefix64 with low priority in case other
RS-NAT routers are failed.
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.
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
Figure 3 illustrates the connection setup in IPv4-IPv6 scenario. The
connection setup follows three steps:
Chen, et al. Expires January 14, 2010 [Page 7]
Internet-Draft RS-NAT July 2009
1) User sends DNS query to DNS4 and the query will be redirected to
DNS6 through a DNS-ALG box. Once the DNS reply reachs the DNS-ALG
box, the box will pick a IPv4 address from the IPv4 address pool and
form a mapping with the IPv6 address form the answer of the DNS
reply. A new DNS relpy will be generated and sent to DNS4 and User.
2) Because the packet translation will be done in the RS-NAT router,
the DNS ALG box should send the mapping info to RS-NAT routers using
new BGP attribute which will be defined in section 6
3) User sends the packet to the IPv4 address got from the answer of
DNS reply. The different IPv4 addresses will lead the packet to
different RS-NAT routers, which is achieved by the RS-NAT routing
function.
Note that in step 1 the DNS-ALG box acts just as DNS-ALG functions
module in NAT-PT box. The difference between the two box is that
DNS-ALG box in our plan is only responsible for the control plan
without packet translation. In addition DNS-ALG box should in charge
of the mapping distribution among those RS-NAT routers
The differences between the two scenarios include two parts:
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 are in the charge of 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.
Chen, et al. Expires January 14, 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
is failed, the address mapping information in the box is lost.
Furthermore, it will cause the flows broke up and reconnection.
The first problem is solved in section 4 in which 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 14, 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 14, 2010 [Page 10]
Internet-Draft RS-NAT July 2009
6. Security Considerations
It needs to be further identified.
Chen, et al. Expires January 14, 2010 [Page 11]
Internet-Draft RS-NAT July 2009
7. IANA Considerations
This memo includes no request to IANA.
Chen, et al. Expires January 14, 2010 [Page 12]
Internet-Draft RS-NAT July 2009
8. References
8.1. Normative References
[RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway
Protocol 4 (BGP-4)", RFC 4271, January 2006.
[RFC2766] Tsirtsis, G. and P. Srisuresh, "Network Address
Translation - Protocol Translation (NAT-PT)", RFC 2766,
February 2000.
[RFC3768] Hinden, R., "Virtual Router Redundancy Protocol (VRRP)",
RFC 3768, April 2004.
[RFC4966] Aoun, C. and E. Davies, "Reasons to Move the Network
Address Translator - Protocol Translator (NAT-PT) to
Historic Status", RFC 4966, July 2007.
8.2. Informative References
[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.miyata-behave-prefix64]
Miyata, H. and M. Bagnulo, "PREFIX64 Comparison",
draft-miyata-behave-prefix64-02 (work in progress),
March 2009.
[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.
Chen, et al. Expires January 14, 2010 [Page 13]
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 14, 2010 [Page 14]
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 14, 2010 [Page 15]