Network Working Group Y. Cui
Internet-Draft J. Wu
Intended status: Standards Track P. Wu
Expires: May 2, 2012 Tsinghua University
Q. Sun
C. Xie
China Telecom
C. Zhou
Huawei Technologies
Y. Lee
Comcast
T. Tsou
Huawei Technologies (USA)
October 30, 2011
Lightweight 4over6 in access network
draft-cui-softwire-b4-translated-ds-lite-04
Abstract
The dual-stack lite mechanism provide an IPv4 access method over IPv6
ISP network for end users. Dual-Stack Lite enables an IPv6 provider
to share IPv4 addresses among customers by combining IPv4-in-IPv6
tunnel and Carrier Grade NAT. However, in dual-stack lite, CGN has
to maintain active NAT sessions, which could become the performance
bottom-neck due to high dynamics of NAT entries, memory cost and log
issue. This document propose the lightweight 4over6 mechanism which
moves the translation function from tunnel concentrator (AFTR) to
initiators (B4s), and hence reduces the mapping scale on the
concentrator to per-customer level. For NAT44 translation usage, the
mechanism allocates port restricted IPv4 addresses to initiators in a
flexible way independent of IPv6 network in the middle.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
Cui, et al. Expires May 2, 2012 [Page 1]
Internet-Draft B4-translated ds-lite October 2011
This Internet-Draft will expire on May 2, 2012.
Copyright Notice
Copyright (c) 2011 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. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Cui, et al. Expires May 2, 2012 [Page 2]
Internet-Draft B4-translated ds-lite October 2011
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 6
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7
4. Lightweight 4over6 Overview . . . . . . . . . . . . . . . . . 8
5. Port Restricted IPv4 Address Allocation . . . . . . . . . . . 9
6. Lightweight 4over6 Initiator Behavior . . . . . . . . . . . . 10
7. Lightweight 4over6 Concentrator Behavior . . . . . . . . . . . 11
8. Fragmentation and Reassembly . . . . . . . . . . . . . . . . . 12
9. DNS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
10. ICMP processing . . . . . . . . . . . . . . . . . . . . . . . 14
11. Mechanism Analysis . . . . . . . . . . . . . . . . . . . . . . 15
12. Security Consideration . . . . . . . . . . . . . . . . . . . . 16
13. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 17
14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Appendix 1. Appendix:Experimental Result . . . . . . . . . . . . 20
1.1. Experimental environment . . . . . . . . . . . . . . . . . 20
1.2. Experimental results . . . . . . . . . . . . . . . . . . . 21
1.3. Coexistent test with DS-Lite . . . . . . . . . . . . . . . 22
1.4. Conclusions . . . . . . . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23
Cui, et al. Expires May 2, 2012 [Page 3]
Internet-Draft B4-translated ds-lite October 2011
1. Introduction
Dual-stack lite technology[RFC6333] provides IPv4 access over IPv6
access network. Dual-Stack lite (DS-lite) also mitigates IPv4
address exhaustion by sharing public IPv4 addresses amongst users.
The B4 element establishes an IPv4-in-IPv6 softwire to the AFTR and
encapsulates the IPv4 packets into the softwire. When AFTR receives
the IPv6 packets, it will decapsulate them and perform NAT-44 on the
packets. This procedure allows AFTR to dynamically assign sessions
to users when needed; hence, increases port-sharing radio and
utilization. There is a trade-off, though. The AFTR is required to
maintain active NAT sessions. In the centralized deployment model
where one AFTR serves thousands of users, the large numbers of NAT
sessions may become performance bottom-neck. First, maintaining
active NAT sessions requires AFTR constantly creating and purging NAT
sessions. Second, a large NAT table demands more processing power
for searching and more memory space. In addition, dynamic session-
based NAT will create large number of log entries, which will also be
a challenging problem.
To address these issues, we propose an extension to DS-lite. We
propose to create rule mapping in the AFTR and distributes the
dynamic NAT table into B4 elements. The B4 element will be
provisioned with an IPv6 address, an IPv4 address and a port-set.
The IPv6 address will be used to create the Softwire. The IPv4
address and port-set will be used for NAT-44 in the home
gateway(CPE). Most CPE have been performing NAT-44 today. The CPE
will perform PAT on user's packets with the IPv4 address and port-set
provisioned by the ISP. The packets are forwarded between the CPE
and the AFTR by IPv6 encapsulation over the tunnel. The AFTR will
maintain a mapping entry with the IPv6 address, IPv4 address and port
set per user. For inbound IPv4 packet on AFTR, it would use the IPv4
destination address and port as the index and use the forwarding rule
in the mapping table to encapsulate the packets to the destination
CPE. The AFTR would not create NAT entry per sessions. This will
significantly reduce the AFTR's NAT table size.
Compared to DS-lite, this extension reduces the AFTR NAT table size.
Each entry represents a B4 element. This also relaxes the
requirement to create a log entry per dynamic session. AFTR only
needs to keep a log entry per B4 element. This is also an extended
case which covers addressing sharing for
[I-D.cui-softwire-host-4over6]. However, the extension will decrease
IPv4 address utilization. Moreover, since port randomization
algorithm must use ports within this port-set, it may cause the port
randomization algorithm more predictable.
Compared to stateless solutions with port set/set allocation such as
Cui, et al. Expires May 2, 2012 [Page 4]
Internet-Draft B4-translated ds-lite October 2011
4rd, this mechanism is suitable for operators who prefers to keep
IPv6 and IPv4 addressing separated. For example, an operator may
want to provide IPv4 with an on-demand way in its IPv6 network, the
dynamic allocation of IPv4 address and port makes more efficient
usage of IPv4 resource. Another example is that an operator may only
have many small and discontinuous IPv4 blocks available to provide
IPv4 over IPv6, rather than a few big IPv4 blocks. This mechanism
keeps dynamic feature of IPv4-IPv6 address binding as in DS-Lite, so
it won't require to administrate and manage many 4rd domains in the
network and mapping rules in the CPEs.
Cui, et al. Expires May 2, 2012 [Page 5]
Internet-Draft B4-translated ds-lite October 2011
2. Requirements Language
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 [RFC2119].
Cui, et al. Expires May 2, 2012 [Page 6]
Internet-Draft B4-translated ds-lite October 2011
3. Terminology
Starting from here, the document will use the terminologies of
lightweight 4over6 instead of DS-lite for distinction.
Lightweight 4over6: lightweight 4over6 is an IPv4-over-IPv6 hub and
spoke mechanism proposed in this document, which supports address
sharing to deal with IPv4 address exhaustion, and places the IPv4
translation on the initiator side.
Lightweight 4over6 initiator (or "initiator" for short): the tunnel
initiator in lightweight 4over6 mechanism. The lightweight 4over6
initiator could be a host directly connected to IPv6, or an dual-
stack CPE in front of an IPv4 local network. It is responsible for
IPv4 public-private translation besides tunnel encapsulation and
decapsulation.
Lightweight 4over6 concentrator (or "concentrator" for short): the
tunnel concentrator in lightweight 4over6 mechanism. The lightweight
4over6 concentrator connects the ISP IPv6 network and IPv4 Internet.
It provides tunnel encapsulation and decapsulation but no IPv4
public-private translation.
Port Restricted IPv4 Address: A public IPv4 address with restricted
port set. In lightweight 4over6, multiple initiators will share the
same IPv4 address, while the port sets are disjoint from each other.
Cui, et al. Expires May 2, 2012 [Page 7]
Internet-Draft B4-translated ds-lite October 2011
4. Lightweight 4over6 Overview
Figure 1 provides an overview of the lightweight 4over6 mechanism. A
lightweight 4over6 initiator which can be either an IPv6 hosts or
CPE, and the lightweight 4over6 concentrator are separated by the
IPv6 network in the middle, so they use IPv4-in-IPv6 tunnel to build
IPv4 connectivity. An initiator uses IPv4 address with restricted
port set for this IPv4 connectivity, which is acquired through either
DHCPv4 with the concentrator, or through PCP with the PCP server.
The concentrator keeps the mapping between initiator's IPv6 address
and the allocated IPv4 address + port set.
+-------------------------+
| IPv6 ISP Network |
| |
+---------+ |
|LW 4over6|Host |
|Initiator|===============+---------+ +-----------+
+---------+ |LW 4over6| | IPv4 |
+--------+ | IPv4-in-IPv6 |Concen- |---| Internet |
| | +---------+ |trator | | |
|IPv4 LAN|--|LW 4over6|===============+---------+ +-----------+
| | |Initiator|CPE |DHCPv4
+--------+ +---------+ +----------+ |Server(Relay)
| |PCP Server| |
| +----------+ |
+-------------------------+
Figure 1 Lightweight 4over6 overview
Cui, et al. Expires May 2, 2012 [Page 8]
Internet-Draft B4-translated ds-lite October 2011
5. Port Restricted IPv4 Address Allocation
As is described above, a lightweight 4over6 initiator needs the
public address and port for stateful translation. This is achieved
by basic PCP mechanism [I-D.ietf-pcp-base]. It's obvious that
individual, realtime address + port allocation is not efficient due
to round-trip time delay and high signaling volume caused. A
practical manner would be allocating and address and a group ports at
one time beforehand, i.e., allocating port restricted IPv4 address.
To our knowledge there're two methods which are probably suitable for
restricted address allocation from concentrator to initiator. One is
extending DHCP to support address allocation with port set embedded.
[I-D.bajko-pripaddrassign] discusses this DHCP usage. In this
special context, we need to build the DHCPv4 procedure over IPv6
[I-D.cui-dhc-dhcpv4-over-ipv6]. The other is extending PCP to
support port set control. See [I-D.tsou-pcp-natcoord] for details.
Adopting either method, an initiator can get port restricted IPv4
address allocated dynamically from the concentrator. Meanwhile, the
dynamic mapping rule between IPv4 address, port set and IPv6 address
are recorded on the concentrator in the initiation phase. Unlike
stateless 4over6 solutions such as [I-D.murakami-softwire-4rd], the
port restricted address allocation in lightweight 4over6 has no
requirement on careful planning of the IPv6 domain range, IPv4/IPv6
mapping relationship, prefix length and multiplex ratio, etc.
Cui, et al. Expires May 2, 2012 [Page 9]
Internet-Draft B4-translated ds-lite October 2011
6. Lightweight 4over6 Initiator Behavior
A lightweight 4over6 initiator should discover the concentrator's
IPv6 address during startup. This IPv6 address can be learned
through a variety of methods, ranging from an out-of-band mechanism,
manual configuration, or a DHCPv6 option. For DHCPv6 case, the
DHCPv6 option should carry the concentrator's IPv6 address
information. The AFTR-Name option [RFC6334] can be applied here;
however, using the same option may cause confusion when both
lightweight 4over6 and dual-stack lite are deployed in one network.
In that case, it is better we define a new DHCPv6 option for
lightweight 4over6 concentrator discovery.
A lightweight 4over6 initiator should support either extended DHCP
client, or extended PCP client, as is described above. When
requiring IPv4 access, the initiator runs either client(according to
the support of the concentrator) to get a port restricted IPv4
address, and renew/extend it when the lease/lifetime is about to
expire.
The data plane functions of the initiator includes translation and
encapsulation/decapsulation. For CPE initiator case, the initiator
runs a standard local NAT44 with the address pool consisting of the
allocated port restricted address. When receiving an IPv4 packet
with private source address from its end hosts, it performs NAT44
function and translates the source address into public. Then it
encapsulates the packet with the concentrator's IPv6 address as
destination IPv6 address, and forwards it to the concentrator. When
receiving an IPv4-in-IPv6 packet from the concentrator, the initiator
decapsulates the IPv6 packet to get the IPv4 packet with public
destination IPv4 address. Then it performs NAT44 function and
translates the destination address into private.
For host initiator case, end host gets public address directly. It
is also suggested that the host run a local NAT to map randomly
generated ports into the restricted, valid port set. Private-public
address translation would not be needed in this NAT. Another
solution is to have the IP stack to only assign ports within the
restricted, valid range to applications. Either way the host
guarantees that every source port number in the packets sent out by
itself falls into the allocated port set.
Cui, et al. Expires May 2, 2012 [Page 10]
Internet-Draft B4-translated ds-lite October 2011
7. Lightweight 4over6 Concentrator Behavior
The lightweight 4over6 concentrator should either allocate port
restricted addresses directly(by performing an extended DHCPv4
server, or an extended PCP server), or leave the allocation to
dedicated DHCP/PCP server(and perform a relay in DHCP case). When
accomplishing one such allocation, the concentrator simultaneously
install a mapping entry into the mapping table. This entry consists
of the public IPv4 address, the port set and initiator's IPv6
address. Its lifetime is set according to the allocation. It'll be
used for encapsulation of inbound packets. This mapping entry will
be deleted when the lifetime expires. The lifetime of the mapping
entry will be refreshed when the initiator renews/extends the
allocation.
The data plane functions of the concentrator is purely encapsulation
and decapsulation. When receiving an IPv4-in-IPv6 packet from an
initiator, the concentrator decapsulates it and forwards it to IPv4
Internet. When receiving an IPv4 packet from the Internet, it uses
the destination address and port from this packet to lookup the
destination initiator's IPv6 address in the mapping table. Then the
concentrator encapsulates this packet using the IPv6 address found in
the table as IPv6 destination address, and forwards it to the correct
initiator based on native IPv6 routing. Hence there is no port-set
routing in IPv6 network anymore.
Cui, et al. Expires May 2, 2012 [Page 11]
Internet-Draft B4-translated ds-lite October 2011
8. Fragmentation and Reassembly
There is no change to section 5.3 and section 6.3 of [RFC6333] in
fragmentation and reassembly behavior, on either side of the tunnel.
Cui, et al. Expires May 2, 2012 [Page 12]
Internet-Draft B4-translated ds-lite October 2011
9. DNS
The DNS consideration is also the same to section 5.5 and section 6.4
in [RFC6333].
Cui, et al. Expires May 2, 2012 [Page 13]
Internet-Draft B4-translated ds-lite October 2011
10. ICMP processing
ICMP availability would become a challenge in port restricted address
environment. To support ICMP "session" initiated from a lightweight
4over6 initiator, the mechanism divides ICMP id field in the same way
with dividing port space, i.e. each initiator will get the ICMP id
range which is identical to the allocated port set. An initiator
only uses the allocated address and restricted id range when send out
an ICMP request. Hence the concentrator can encapsulate the
corresponding ICMP reply correctly according to the ICMP id field.
The inbound ICMP request would be left unsupported on the
concentrator, which is the similar behavior of NAT/CGN. See details
about ICMP processing in section 4.2 of [I-D.sun-v6ops-laft6]
Cui, et al. Expires May 2, 2012 [Page 14]
Internet-Draft B4-translated ds-lite October 2011
11. Mechanism Analysis
Compared with original dual-stack lite, lightweight 4over6 removes
the translation burden from the concentrator and distribute the job
to initiators on user-side. Also it decreases the state scale on
concentrator from per-session level down to per-user level. This
would significantly reduce the hardware cost of the concentrator, and
relieve the situation that the concentrator becomes the performance
bottleneck. Leveraging lightweight 4over6, one concentrator can
serve a lot more customers.
Besides, since this mechanism reduces the number of simultaneous
address mappings of each customer on concentrator to one, it makes
concentrator logging much more feasible. Moreover, locating the
translation on user side eases the ALG and NAT referral problem since
it'll be no different from the situation of local NAT in today's IPv4
network. Solutions like uPnP already exist for quite a long time.
Most current CPEs have already implemented NAT44 functionalities,
lightweight 4over6 would not bring a lot more complexity to existing
CPEs.
Lightweight 4over6 allocates port restricted address independent of
the IPv6 network in the middle. No specific IPv6 address format is
required. IPv4 and IPv6 addressing and routing remain separated.
The ISP can provide IPv4 in a flexible, on-demand way, as well as
manage the native IPv6 network without the influence of IPv4-over-
IPv6 requirements. And it would also be easy to achieve future
adjustment of IPv4 address pool.
The costs of lightweight 4over6 for achieving all these benefits are
lower IPv4 address utilization ratio and extra signaling behavior.
The address multiplexing manner of port restricted address is
relatively more static than dual-stack lite. And dual-stack lite
doesn't require address and port allocation between concentrator and
initiators. When compared to stateless solutions, lightweight 4over6
still keeps per-user states rather than becoming purely stateless.
Cui, et al. Expires May 2, 2012 [Page 15]
Internet-Draft B4-translated ds-lite October 2011
12. Security Consideration
Since port randomization algorithm must use ports within the port
set, it may cause the port randomization algorithm more predictable.
Therefore, non-continuous port set algorithms (e.g. as defined in
[I-D.mdt-softwire-mapping-address-and-port]) can be introduced to
further improve the security.
Cui, et al. Expires May 2, 2012 [Page 16]
Internet-Draft B4-translated ds-lite October 2011
13. Acknowledgement
The authors would like to thank Alain Durand, Ole Troan, Ralph Droms
and Xiaohong Deng for their comments and feedback.
Cui, et al. Expires May 2, 2012 [Page 17]
Internet-Draft B4-translated ds-lite October 2011
14. References
[I-D.bajko-pripaddrassign]
Bajko, G., Savolainen, T., Boucadair, M., and P. Levis,
"Port Restricted IP Address Assignment",
draft-bajko-pripaddrassign-03 (work in progress),
September 2010.
[I-D.bsd-softwire-stateless-port-index-analysis]
Boucadair, M., Skoberne, N., and W. Dec, "Analysis of Port
Indexing Algorithms",
draft-bsd-softwire-stateless-port-index-analysis-00 (work
in progress), September 2011.
[I-D.cui-dhc-dhcpv4-over-ipv6]
Cui, Y., Wu, P., Wu, J., and T. Lemon, "DHCPv4 over IPv6
transport", draft-cui-dhc-dhcpv4-over-ipv6-00 (work in
progress), October 2011.
[I-D.cui-softwire-host-4over6]
Cui, Y., Wu, J., Wu, P., Metz, C., Vautrin, O., and Y.
Lee, "Public IPv4 over Access IPv6 Network",
draft-cui-softwire-host-4over6-06 (work in progress),
July 2011.
[I-D.ietf-pcp-base]
Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P.
Selkirk, "Port Control Protocol (PCP)",
draft-ietf-pcp-base-16 (work in progress), October 2011.
[I-D.mdt-softwire-mapping-address-and-port]
Troan, O., "Mapping of Address and Port (MAP)",
draft-mdt-softwire-mapping-address-and-port-00 (work in
progress), October 2011.
[I-D.murakami-softwire-4rd]
Murakami, T., Troan, O., and S. Matsushima, "IPv4 Residual
Deployment on IPv6 infrastructure - protocol
specification", draft-murakami-softwire-4rd-01 (work in
progress), September 2011.
[I-D.sun-v6ops-laft6]
Sun, Q. and C. Xie, "LAFT6: Lightweight address family
transition for IPv6", draft-sun-v6ops-laft6-01 (work in
progress), March 2011.
[I-D.tsou-pcp-natcoord]
Zhou, C., ZOU), T., Deng, X., Boucadair, M., and Q. Sun,
Cui, et al. Expires May 2, 2012 [Page 18]
Internet-Draft B4-translated ds-lite October 2011
"Using PCP To Coordinate Between the CGN and Home Gateway
Via Port Allocation", draft-tsou-pcp-natcoord-03 (work in
progress), July 2011.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual-
Stack Lite Broadband Deployments Following IPv4
Exhaustion", RFC 6333, August 2011.
[RFC6334] Hankins, D. and T. Mrugalski, "Dynamic Host Configuration
Protocol for IPv6 (DHCPv6) Option for Dual-Stack Lite",
RFC 6334, August 2011.
Cui, et al. Expires May 2, 2012 [Page 19]
Internet-Draft B4-translated ds-lite October 2011
1. Appendix:Experimental Result
We have deployed lightweight 4over6 in our operational network of
HuNan province, China. It is designed for broadband access network,
and different versions of initiator have been implemented including a
linksys box, a software client for windows XP, vista and Windows 7.
It can be integrated with existing dial-up mechanisms such as PPPoE,
etc. The major objectives listed below aimed to verify the
functionality and performance of lightweight 4over6:
o Verify how to deploy lightweight 4over6 in a practical network.
o Verify the impact of applications with lightweight 4over6.
o Verify the performance of lightweight 4over6.
o Verify the coexistence between lightweight 4over6 and DS-Lite.
1.1. Experimental environment
The network topology for this experiment is depicted in Figure 2.
+--------+
+-----+ +---------+ | Syslog |
|Host1+--+Initiator|--+ | Server | --------
+-----+ +---------+ | +---+----+ /// \\\
| /------\ | // \\
| // \\ +---+----+ | |
+-----+ +---------+ +-+--+ | IPv6 | | | | IPv4 Internet |
|Host2+--|Initiator|--+BRAS+--| Network |---| Concen-+-+ |
+-----+ +---------+ +-+--+ \\ // | trator | \\ //
| \---+--/ +--------+ \\\ ///
| | ---------
+-----+ +---------+ | |
|Host3+--+Initiator+---+ |
+-----+ +---------+ | --------
| // \\
| / \
+---------------------+IPv6 Internet +
| |
\ /
\\ //
-------
Figure 2 Lightweight 4over6 experiment topology
In this deployment model, concentrator is co-located with a extended
PCP server to assign restricted IPv4 address and port set for
Cui, et al. Expires May 2, 2012 [Page 20]
Internet-Draft B4-translated ds-lite October 2011
initiator. It also triggers subscriber-based logging event to a
centrilized syslog server. IPv6 address pools for subscribers have
been distributed to BRASs for configuration, while the public
available IPv4 address pools are configured by the centralized
concentrator with a default address sharing ratio. It is rather
flexible for IPv6 addressing and routing, and there is little impact
on existing IPv6 architecture.
In our experiment, initiator will firstly get its IPv6 address and
delegated prefix through PPPoE, and then initiate a PCP-extended
request to get public IPv4 address and its valid port set. The
concentrator will thus create a subscriber-based state accordingly,
and notify syslog server with {IPv6 address, IPv4 address, port set,
timestamp}.
1.2. Experimental results
In our trial, we mainly focused on application test and performance
test. The applications have widely include web, email, Instant
Message, ftp, telnet, SSH, video, Video Camera, P2P, online game,
voip and so on. For performance test, we have measured the
parameters of concurrent session numbers and throughput performance.
The experimental results are listed as follows:
+--------------------+----------------------+-----------------------+
| Application Type | Test Result |Port Number Occupation |
+--------------------+----------------------+-----------------------+
| Web | ok | normal websites: 10~20|
| | IE, Firefox, Chrome | Ajex Flash webs: 30~40|
+--------------------+----------------------+-----------------------+
| Video | ok, web based or | 30~40 |
| | client based | |
+--------------------+----------------------+-----------------------+
| Instant Message | ok | |
| | QQ, MSN, gtalk, skype| 8~20 |
+--------------------+----------------------+-----------------------+
| P2P | ok | lower speed: 20~600 |
| |utorrent,emule,xunlei | (per seed) |
| | | higher speed: 150~300 |
+--------------------+----------------------+-----------------------+
| FTP | need ALG for active | 2 |
| | mode, flashxp | |
+--------------------+----------------------+-----------------------+
| SSH, TELNET | ok |1 for SSH, 3 for telnet|
+--------------------+----------------------+-----------------------+
| online game | ok for QQ, flash game| 20~40 |
+--------------------+----------------------+-----------------------+
Cui, et al. Expires May 2, 2012 [Page 21]
Internet-Draft B4-translated ds-lite October 2011
Figure 3 Lightweight 4over6 experimental result
The performance test for concentrator is taken on a normal PC. Due
to limitations of the PC hardware, the overall throughput is limited
to around 800 Mbps. However, it can still support more than one
hundred million concurrent sessions.
1.3. Coexistent test with DS-Lite
In our coexistent test for lightweight 4over6 and DS-Lite, both
lightweight concentrator and DS-Lite AFTR have run in the same PC.
Two different virtual interfaces are configured with 4over6
concentrator IPv6 addresses and DS-lite AFTR IPv6 address, which will
be notified to the initiators and B4s seperately. Besides, seperated
public IPv4 address pools have been configured for these two
approaches. Each CPE would only run one mechanism, either
lightweight 4over6 or DS-Lite.
For outbound traffic arriving at the concentrator, it will be routed
either to 4over6 concentrator or DS-Lite AFTR interface according to
different destination addresses. While for inbound IPv4 traffic, it
will also be destinated to different interfaces based on seperated
destination IPv4 address pools.
1.4. Conclusions
From the experiment, we can have the following conclusions:
o Lightweight 4over6 has good scalability. As it is a lightweight
solution which only maintains per-subscriber state information, it
can easily support a large amount of concurrent subscribers.
o Lightweight 4over6 can be deployed rapidly. There is no
modification to existing addressing and routing system in our
operational network. And it is simple to achieve traffic logging.
o Lightweight 4over6 can support a majority of current IPv4
applications.
o Lightweight 4over6 can be coexistent with DS-Lite easily.
Cui, et al. Expires May 2, 2012 [Page 22]
Internet-Draft B4-translated ds-lite October 2011
Authors' Addresses
Yong Cui
Tsinghua University
Department of Computer Science, Tsinghua University
Beijing 100084
P.R.China
Phone: +86-10-62603059
Email: yong@csnet1.cs.tsinghua.edu.cn
Jianping Wu
Tsinghua University
Department of Computer Science, Tsinghua University
Beijing 100084
P.R.China
Phone: +86-10-62785983
Email: jianping@cernet.edu.cn
Peng Wu
Tsinghua University
Department of Computer Science, Tsinghua University
Beijing 100084
P.R.China
Phone: +86-10-62785822
Email: weapon@csnet1.cs.tsinghua.edu.cn
Qiong Sun
China Telecom
Room 708, No.118, Xizhimennei Street
Beijing 100035
P.R.China
Phone: +86-10-58552936>
Email: sunqiong@ctbri.com.cn
Chongfeng Xie
China Telecom
Room 708, No.118, Xizhimennei Street
Beijing 100035
P.R.China
Cui, et al. Expires May 2, 2012 [Page 23]
Internet-Draft B4-translated ds-lite October 2011
Phone: +86-10-58552116>
Email: xiechf@ctbri.com.cn
Cathy Zhou
Huawei Technologies
Section B, Huawei Industrial Base, Bantian Longgang
Shenzhen 518129
P.R.China
Phone: +86-10-58552116
Email: cathyzhou@huawei.com
Yiu L. Lee
Comcast
One Comcast Center
Philadelphia, PA 19103
USA
Email: yiu_lee@cable.comcast.com
Tina Tsou
Huawei Technologies (USA)
2330 Central Expressway
Santa Clara, CA 95050
USA
Phone: +1 408 330 4424
Email: tena@huawei.com
Cui, et al. Expires May 2, 2012 [Page 24]
