DTTS: A Transparent and Scalable Solution for IPv4 to IPv6 Transition

Kai Wang, Ann-Kian Yeo, A. L. Ananda

Center for Internet Research
School of Computing
National University of Singapore
3 Science Drive 2, Singapore 117543
{wangkai1, yeoak, ananda}@comp.nus.edu.sg

Abstract - IPv4 to IPv6 transition is an inevitable process

when deploying IPv6 networks within the present IPv4 Internet.
The transition process is complex as it has to deal with issues
related to IPv4-IPv6 interoperability including routing, DNS,
error handling, etc. In this paper, a new solution named DTTS
(Dynamic Tunneling Transition Solution) for IPv4 to IPv6
transition based on dynamic tunneling technique and dual stack
approach is presented. Dynamic tunneling technique is used to
encapsulate an IPv4 packet in an IPv6 packet to achieve
transparent and scalable transition. This technique, coupled
with the dual stack approach, enables IPv4 applications to run
and interact with other IPv4 applications in both IPv4 and IPv6
network environments without any modification and recompilation, and without NAT, nor any application proxy or gateway.

Keywords: Interoperability, IPv4, IPv6, Transition, Dynamic Tunneling, Dual Stack.

I. INTRODUCTION
IPv6[1] and IPv4 protocols do not interoperate, and hence
IPv4 applications do not work in IPv6 environment and vice
versa. However, the deployment of IPv6 within the present
IPv4 Internet will be on an incremental basis and start from
small IPv6 networks that merge into the global IPv6 network
gradually. It is envisaged that a short-medium term coexistence of both IPv6 and IPv4 is inevitable. During the
transition phase, due to lack of IPv6 applications and
services, any transition solution should incorporate mechanisms for existing IPv4 applications to run in IPv6 networks.
The fundamental question that needs to be addressed is: How
to enable transparent communication between the existing
IPv4 network and the new IPv6 network?[17]
To date, a set of IPv4 to IPv6 transition mechanisms and
tools have been put forward to address the above issues. Of
the known mechanisms, which are discussed in Section V,
both NAT-based and proxy-based techniques have inherent
weaknesses that deter their full-scale deployment. For
example, some lack an end-to-end IP communication, or
others require application gateways for address translation. In
addition, none of these mechanisms scales well.
In this proposal, our motivation is to design a viable solution: i) to enable transparent end-to-end IP communication
between IPv4 nodes and IPv6 nodes; ii) to be capable of
scalable deployment; iii) to enable IPv4 based applications to
run in IPv6 networks seamlessly. In order to achieve theses
goals and enable incremental deployment of IPv6 networks
within the IPv4 based Internet, we have proposed a new
solution named DTTS (Dynamic Tunneling Transition
Solution). DTTS employs the dual stack approach coupled

0-7803-7128-3/01/$10.00 (C) 2001 IEEE

248

with dynamic tunneling technique to offer a transparent and

scalable IPv4 to IPv6 transition. In DTTS, each host uses a
private IPv4 address[9] and a dynamically assigned global
IPv4 address to enable end-to-end IP communication. With
this solution, users in new IPv6 networks could obtain service
from the existing Internet, and users in the Internet could
communicate with the newly deployed IPv6 networks.
Moreover, more than one border routers equipped with
DTTS, which serve as tunnel endpoints, could be deployed
on the IPv6 and IPv4 network boundary. If one of the border
routers fails, the IPv6-IPv4 communication could still
continue. Thus, this improves overall system reliability.
The rest of this paper is organized as follows. Section II
introduces DTTS, followed by a detailed description of
various aspects of DTTS including address allocation,
dynamic tunneling technique, DNS, ICMP, and routing
issues. Section III describes the implementation and prototype system. Section IV discusses the limitations of DTTS
and its deployment strategies. We present some related work
in Section V and conclude with future work in Section VI.
II. S YSTEM O VERVIEW
In DTTS, each host in an IPv6 network has dual stacks
(IPv4 & IPv6). Only IPv6 traffic is supported within the
network, and routers understand only IPv6 protocol. Border
routers that also have dual stack connect to both IPv6 and
IPv4 networks as showed in Fig. 1.
For end-to-end IP communication between IPv4 and IPv6
hosts, the dynamic tunneling technique is used to encapsulate
IPv4 packets in IPv6 to travel in the IPv6 network based on
IPv6 routing without tunnel endpoint configuration. Border
routers serve as tunnel endpoints and forward IPv6 packets to
IPv4 networks and vice versa. When a border router receives
tunnel packets, it decapsulates the tunnel header and forward
them to IPv4 networks. On the other hand, when a border
router receives IPv4 packets, it encapsulates them with the
IPv6 tunneling header and transmits to the IPv6 host. The
encapsulation effectively suppresses the direct movement of
IPv4 packets within an IPv6 network, and instead allows their
movement based only on IPv6 routing tables, thereby
simplifying the IPv6 network management.
Within the IPv6 network, each dual stack host communicates only in IPv6 or IPv6-encapsulated packets. An IPv4
application running on an IPv6 node uses either a private
IPv4 address to talk to another IPv4 application within the
IPv6 network; or use dynamically assigned public IPv4

address to talk to another IPv4 application in the Internet.

Since only IPv6 packets are allowed within the IPv6 network,
all private-address or public-address IPv4 packets within the
IPv6 network must be encapsulated with IPv6 headers with
the help of dual stack approach and the dynamic tunneling
technique.
Global IPv4
Address Pool

Address Allocation
Server

IPv4 DNS
Server
IPv6-only Router
R1

Border Router
BR
(Dual stack)

IPv6
Network

IPv6 node A
(Dual stack)

IPv4 Network
DNS
Proxy

IPv6-only Router
R2

IPv6-only Router
R3
IPv6-IPv4 address
mapping table

IPv6-to-IPv6 scenario. This includes IPv4 DNS resolutions

requested by IPv4 applications to the private DNS server. A
node may also be assigned dynamically a public IPv4 address
by the AAS (see Section III). Public IPv4 addresses are used
in IPv6-to-IPv4 and IPv4-to-IPv6 scenarios.
As far as IPv6 address is concerned, each interface of an
IPv6 node can have multiple IPv6 addresses, for example,
link local address, site local address, aggregatable global
unicast address[10], etc. In DTTS, each host is assigned an
IPv4-compatible address[10], which is constructed by
prepending a null prefix, made of 96 zero bits, to a 32-bit
IPv4 private address. IPv4-compatiable addresses are used for
IPv6-to-IPv6 scenario. Also, each host is assigned a site local
address through IPv6 stateless autoconfiguration mechanism[11]. Site local addresses are used for IPv4-to-IPv6 and
IPv6-to-IPv4 scenarios from hosts to border routers and vice
versa.

IPv4 node C

B. Dynamic Tunneling Technique

IPv6 node B
(Dual stack)

Private
DNS Server

Fig. 1. A generic IPv6 transition environment

Fig. 1 shows DTTS with its components:

Dual stack host: a host in an IPv6 network with both

IPv4 and IPv6 stacks. Both IPv4 and IPv6 based applications
can run on this host.

Address Allocation Server (AAS): a server which

can dynamically allocate addresses to dual stack hosts from
its global IPv4 address pool.

Private DNS server: a BIND server providing normal DNS functions that can resolve both private IPv4
addresses and IPv6 addresses for the IPv6 network.

Border router: a dual stack router sitting on the

boundary between an IPv6 and an IPv4 network. The router
maintains an IPv6-IPv4 address mapping table for each
outbound and inbound packet. A DNS proxy running on the
border router relays DNS messages to/from the private DNS
server.

With DTTS, the IPv6 protocol layer is considered as a link

layer for the IPv4 protocol layer. The encapsulation of IPv4
packets in IPv6 packets coupled with dual stack helps in
deploying IPv4 applications in an IPv6 network node and
also to eliminate IPv4 routing in the IPv6 network. Fig. 2
depicts the general protocol layers of a dual stack node.
Application (HTTP, FTP)

TCPv4

TCPv6

IPv4

IPv6

Data Link Layer ( Ethernet )

Fig. 2. General protocol layer of a dual stack node

IPv6-to-IPv6 scenario: the communication from a

dual stack node to another dual stack node in the IPv6
network, e.g., node A to node B via IPv6-only router R2.

We use the term dynamic tunneling to emphasize its

characteristics distinguished from the traditional tunneling
technique. Traditionally, a tunnel is a point-to-point link
between two tunnel endpoints. Before setting up a tunnel, the
tunnel entrypoint and endpoint addresses are obtained
through manual configuration or other dynamic methods. But
the tunnel lacks flexibility and the router which serves as
tunnel endpoint is a single point of failure. On the other hand,
dynamic tunneling technique employed by DTTS need not
know the tunnel endpoint addresses before setting up the
tunnel, thus enhances the system scalability and flexibility.
The detailed tunneling processes are considered in the
following subsections for host-to-host, host-to-router and
route-to-host tunneling modes.

A. Dual Stack Hosts Address Allocation

1) Host-to-host Tunneling Mode

A dual stack node in DTTS has both IPv4 and IPv6 addresses assigned to its interfaces. Each node has a private
IPv4 address assigned either statically or through a DHCP
server. Private addresses are used by IPv4 applications in the

Host-to-host tunneling mode is used in the IPv6-to-IPv6

communication scenario and is very straightforward. When
an IPv4 packet reaches the IPv6 layer, its source and
destination addresses are already known. No other process is

The following three typical communication scenarios are

considered while describing components of DTTS:

IPv6-to-IPv4 scenario: the communication from a

dual stack node in the IPv6 network to an IPv4 node in the
Internet, e.g., node A to node C via border router BR.

IPv4-to-IPv6 scenario: the communication from an

IPv4 node in the Internet to a dual stack node in the IPv6
network, e.g., node C to node A via border router BR.

249

needed but to insert 96-bit zeros before the IPv4 source and
the destination address to complete the encapsulation. Since
each node within the IPv6 network has been configured with
an IPv4-compatible address, IPv6 tunnel packets reach the
destination host directly. Fig. 3 illustrates the encapsulation
process.
IPv4 SA: 10.0.0.1/24
IPv4 DA: 10.0.1.1/24

IPv4
Header

IPv4 Payload

The source IPv6 address is the IPv6 site local address of the
border router. Fig. 5 illustrates this encapsulation process.
subnet bit of the
Border Router

IPv4 SA: 188.166.2.10

IPv4 DA: 137.132.89.92
EUI-64
interface ID

IPv6
Tunnel Header

IPv4
Payload

IPv6 SA: fec0::2:2d0:b7ff:fe6b:ca1b/64

IPv6 DA: fec0::0:200:94ff:fea9:9f62/64

IPv6 SA: ::10.0.0.1/120

IPv6 DA: ::10.0.1.1/120

IPv4
Header

IPv6
Tunnel Header

IPv4 Packet

obtain the IPv6 address from the address mapping table

( the IPv6 address binding pair of 137.132.89.92 )

IPv4 Packet

Fig. 5. A router-to-host encapsulation process example

Fig. 3. A host-to-host encapsulation process example

C. DNS Issues

2) Host-to-router Tunneling Mode

The host-to-router tunneling takes place in the IPv6-toIPv4 and IPv4-to-IPv6 communication scenarios, as IPv4
packets are tunneled from IPv6 hosts to border routers. At the
sending host, when IPv4 packets reach the IPv6 link layer,
the IPv6 destination address of the tunnel header is constructed as an IPv6 site local address. This site local address
consists of site local address prefix(fec0), subnet bit and 64bit interface ID. The subnet bit is selected differently from
all existing local subnet bits for uniquely indicating the
outbound communication. The administrators can designate it
randomly provided that the IPv6 packets with that 64-bit
prefix could be routed to border routers. In DTTS, for
indicating the destination, the last 64-bit is constructed with
32-bit zeros and the 32-bit destination IPv4 address. The
source IPv6 site local address is just the site local address of
the nodes interface. It is selected automatically based on
IPv6 source address selection. Fig. 4 illustrates this encapsulation process.
site local
prefix

IPv4 SA: 137.132.89.92

IPv4 DA: 188.166.2.10
subnet EUI-64
bit interface ID

IPv6 SA: fec0::0:200:94ff:fea9:9f62/64

IPv6
Tunnel Header

IPv4
Header

IPv4
Payload

IPv4 Packet

IPv6 DA: fec0::ff00:0:0:bca6:20a/64

subnet bit

the construted interface ID from the IPv4 DA.

( in this case: 188.166.2.10 )

Fig. 4. A host-to-router encapsulation process example

The merit of this encapsulation process is that hosts need

not be configured statically or through other dynamic
methods with the tunnel endpoint address to proceed with
tunneling. IPv6 packets are routed to border routers based on
IPv6 routing. The routing issues are discussed in subsection
E.
3) Router-to-host Tunneling Mode
The router-to-host tunneling mode is used in the IPv4-toIPv6 and IPv6-to-IPv4 communication scenarios, as IPv4
packets are tunneled from border routers to the destination
host. For the IPv6 tunnel header, the IPv6 destination address
is obtained from the address binding records in the IPv6IPv4 address mapping table maintained by the border router.

250

DNS is the most important and integral part for IPv4 to

IPv6 transition. IPv4 name to address mappings are held in
DNS as A records. IPv6 name to address mappings are held
in DNS as AAAA[12] or A6[13] records. In DTTS, the
private DNS server (e.g. BIND which is capable of resolving
A, AAAA and A6 records) must run on a dual-stack
IPv6 node in the IPv6 network. Its role is to resolve both
private and public IPv4 and IPv6 DNS queries. Private IPv4
and IPv6 records are configured in the DNS server for the
hosts in the IPv6 network. Public IPv4 records of IPv4 hosts
in the IPv4 Internet are stored in the cache when the private
DNS server obtains them through referral to an authoritative
server in the IPv4 Internet. Hence, this private DNS server
acts as the authoritative server for the private IPv4 and IPv6
domains within the IPv6 network.
For the IPv6-to-IPv4 and IPv6-to-IPv6 scenarios, no special handling of DNS resolution is required. This is because
IPv4 applications uses IPv4 resolver library to send IPv4
packets to the private DNS server via host-to-host tunnel in
the IPv6 network. On the other hand, for the IPv4-to-IPv6
scenario, a DNS request for an IPv6 node originated from an
IPv4 node essentially needs to be resolved to its temporarily
assigned public IPv4 address for the IPv6 node. A DNS
proxy is running on the border router to act as the authoritative DNS server (in the public IPv4 domain) for the pool of
public IPv4 addresses possessed by the AAS. When the DNS
proxy receives an unresolved DNS request from the Internet
in the IPv4-to-IPv6 scenario, it triggers a series of translation
processes.
Basically, the DNS proxy is a faked DNS server serving
as a translator between DNS messages of IPv4 networks
and DNS messages of IPv6 networks. It establishes its own
policy to filter and translate the payload of DNS packets. It
helps translate name-to-IPv6 mappings in DNS payloads into
name-to-global IPv4 address mappings using the address
mapping states on border routers. The DNS proxy is merely a
DNS relay server and it does not maintain a DNS databases.
It has to cooperate with the AAS and the private DNS server
to resolve all DNS requests. Fig. 6 depicts the DNS proxy
filtering & translation process without dwelling into its
detailed algorithm.
One must note that the TTL values should be left unchanged for statically mapped addresses. The TTL values on
all IPv4 DNS resource records which are temporarily

assigned to IPv6 hosts should be set to 0 so DNS servers/clients do not cache them. For compatibility with broken
implementations, TTL of 1 might in practice work better[19].

packets are forwarded by IPv6 routers as normal IPv6

packets.
IPv6 header

get the DNS

request

ICMP
header

Tunnel IPv6 paket in error

IPv6 tunnel
header

ICMP
header

Original IPv4
header

Original IPv4
packet payload

request type ?
Other types
(CNAME, MX,
etc. )
Othet type
filtering &
translation
procedures

A type filtering
& translation
procedures

PTR

PTR type
filtering &
translation
procedures

NS
New IPv4
header

NS type filtering
& translation
procedures

New IPv4
header

Fig. 6. DNS proxys filtering & translation process

Original IPv4 pacet in error

New ICMPv4 packet

D. ICMP Issues
For achieving transparent communication, ICMP messages have to be handled differently depending on the
origination of ICMP error messages.
1) ICMPv4 Messages Generated Outside the Tunnel
The ICMPv4 messages generated outside the tunnel include the error messages generated in the IPv4 network side,
and the errors generated on the IPv4 layer at dual stack nodes.
In this case, ICMPv4 messages are treated as normal IPv4
traffic from an IPv4 node and are tunneled to the source host.
2) ICMPv6 Messages Generated within the Tunnel

Fig. 7. An ICMPv4 message creation process

1) Routing Configurations on IPv6 Hosts

With respect to the encapsulation processes described in
subsection B, the following two route entries are needed in
the IPv4 routing table of IPv6 hosts:

The route entry for reaching the nodes in other

subnets connected with IPv6-only routers. This entry is for
IPv6-to-IPv6 scenario in which case the host-to-host
tunneling is used for the entire path from the source node to
the destination node.

The most difficult problem to address is ICMPv6[14]

messages generated within the IPv6 network for the packets
carrying IPv4 payload. An ICMPv6 message sent to the
tunnel entry-point node has an ICMPv6 payload which
includes the tunnel IPv6 packet as its payload. After it is
transferred to the tunnel entry-point host, it is handled as
follows.

The default route entry. The default tunnel route is

used to encapsulate all outbound packets destined to IPv4
networks. This entry is for IPv6-to-IPv4 and IPv4-to-IPv6
scenarios in which the host-to-router tunneling is used for the
path from the source host to the border router.

For the IPv6-to-IPv4 scenario and IPv6-to-IPv6

scenario, the tunnel entry-point is just the original source
host, so the host decapsulates the tunnel header, translates it
to an ICMPv4 message, and sends it to the IPv4 layer on the
host.

Border routers in DTTS connect two different routing

regions, that is, an IPv4 and an IPv6 routing region. A border
router must:

For the IPv4-to-IPv6 scenario, an ICMPv6 message

is first transferred to the border router, then the border router
decapsulates its tunnel header, translates it to an ICMPv4
message, and at the end forwards the ICMPv4 message to the
original IPv4 source host.
Fig. 7 depicts the ICMPv4 message creation process[15].
As far as the ICMP message translation is concerned, the
ICMPv6 error messages such as hop limit exceeded and
unreachable node are translated into ICMPv4 messages
with type 3(destination unreachable) and code 1(host
unreachable) respectively.
E. Routing Issues
In DTTS, there is only IPv6 routing infrastructure in IPv6
networks, and IPv4 routing infrastructure in IPv4 networks.
With the dynamic tunneling technique, IPv6 tunneling

251

2) Routing Requirements on Border Routers

for IPv4 routing, advertise reachability for the public

IPv4 addresses belonging to the address pool of the AAS into
the IPv4 routing region;
for IPv6 routing, advertise reachability for its dedi
cated 64-bit site local prefix into IPv6 routing region.
III. IMPLEMENTATION AND PROTOTYPE SYSTEM
DTTS described in this paper has been implemented on
Linux kernel version 2.2.18. The dynamic tunneling function
is realized as a software device in kernel module level. Both
border routers and hosts in DTTS should load this module
into the system to achieve encapsulation and decapsulation.
On an IPv6 host, a user-space Address Allocation Client
daemon, acting as the interface between the dynamic
tunneling module in kernel and the AAS, is serving to
complete the IPv4 address application and address initialization tasks. On a border router, an Address Mapping Table
Operation daemon is running to update the address mapping
table based on the multicast messages from the AAS. A DNS

proxy daemon, sitting on the border router, intercepts DNS

messages directed to or from IPv6 networks and performs
transparent payload translation so that IPv6 hosts in IPv6
networks have the right IPv4 address mappings within IPv4
address realm.
AAS possesses a pool of public IPv4 addresses for dynamic assignment to clients and keeps track of addresses
assigned to IPv6 hosts. Basic renewing, reclaiming and
timing function are also included. Besides the address
assignment, the AAS is designed to be a central control point
for the address mapping tables on all deployed border routers.
When the AAS assigns an IPv4 address to an IPv6 host, it
informs new address binding record to Address Mapping
Table Operation daemons on border routers via IPv6
multicast mechanism simultaneously. With the table synchronization mechanism, all address mapping tables could be
assured to keep consistent address binding records. This
guarantees that IPv4 packets are tunneled to IPv6 hosts
correctly via any border router.
We have set up an IPv6 testbed as described in Fig. 1
within the departmental intranet and deployed DTTS
prototype system in the IPv6 network. On our dual stack
Linux nodes in the IPv6 network, we used available IPv4
applications to communicate with the Internet. We could visit
dual stack hosts within our IPv6 testbed from the Internet
seamlessly. None of IPv4 programs required any modification and/or recompilation to enable them running in the IPv6
network. We have tested some basic network applications
such as telnet, ftp, email, WWW, and we also ran IPv4
version X-windows program from our IPv6 testbed to access
the Unix servers on the IPv4 network. The performance was
acceptable except for the initial delay in assigning a public
IPv4 address to an IPv6 host. The implementation has
successfully demonstrated that the DTTS can provide a
transparent communication between IPv4 and IPv6 nodes, as
well as guarantee end-to-end IP connection.
IV. D ISCUSSION
In this section, we discuss the limitations of DTTS and
issues related to its deployment strategies.
A. DTTS Limitations
Firstly, DTTS requires a pool of global IPv4 addresses for
dynamic assignment to inbound and outbound communications with IPv4 networks. Because of the limited addresses in
the pool, the maximum number of communication sessions is
fixed. When the number of sessions outstrip a specified level,
denial-of-service will occur because of lack of IPv4 addresses, in a way similar to NAT-based solutions. However,
we argue that this limitation is not worse than the current
NAT solutions; moreover DTTS does provide end-to-end IP
communication.
Secondly, in DTTS, each host in IPv6 network has to be
installed with DTTS components which are platformdependent. In addition, with an upgrade of OS, some DTTS
components also need to be upgraded as well. However, if
DTTS can be accepted as a standard and supported by major
vendors, this will not be a problem.

252

B. DTTS Deployment
The IPv6 transition is a gradual process, and it needs a
staged transition plan, especially for large organizations. The
solution offered by DTTS enables IPv4 applications to run in
IPv6 networks without any modification and/or recompilation. This allows one to take advantage of abundant IPv4
applications when deploying IPv6, thus helps speeding up its
deployment. In addition, IPv4 legacy applications can still
run after some network infrastructure is upgraded to IPv6,
thus users present investment can be protected without
hampering the IPv6 deployment.
In general, deploying DTTS within the present IPv4 networks includes the following steps:
1) Upgrade all nodes within a chosen subnet to dual stacks;
2) Upgrade all the routers within the subnet to IPv6-only
routers;
3) Configure all hosts with DTTS client modules and AAS
client programs;
4) Upgrade border routers with DTTS server modules, DNS
proxy applications and Address Table Mapping daemons;
5) Deploy AAS servers with a public IPv4 address pool
within the subnet.
After applying the above steps, an existing IPv4 subnet
will become an IPv6 subnet like an island. With the maturity
of IPv6, these IPv6 islands can eventually merge into a pure
IPv6 network.
V. RELATED WORK
In this section, we review some related works proposed
under IETF Next Generation Transition Working
Group(Ngtrans)[17].
Dual stack[2] mechanism is one of two basic transition
mechanisms, which mandates the complete support for both
IPv4 and IPv6 in hosts and routers. But it does not reduce the
demand for globally routable IPv4 addresses and increases
the network complexity due to the need for a mixture of IPv4
and IPv6 routing infrastructure.
Application Level Gateway(ALG), SOCKS64[3] and TCPRelay[4] are proxy-based mechanisms which can provide
communication between IPv4 nodes and IPv6 nodes. They all
split one IP connection into two closed connections on
application or TCP layer, one is in the IPv4 network and the
other is in the IPv6 network. Their common demerit is that
they break the end-to-end principle of the Internet, which is
important aspect for e-commerce and business communications. ALG is an application-dependent mechanism, which
means for the different applications it should provide
different application gateway components. SOCKS64 can
only be for sockcified sites consisting of SOCKS aware
clients and a SOCKS server.
NATPT[6] is derived from the traditional NAT[16]
mechanism, plus protocol translation between IPv4 and IPv6
protocol. BIS[7] adds an address translator module into the
nodes system, cooperated with an address mapper and an

extension to the name resolver, to facilitate the transition.

SIIT[5] provides a flexible and stateless translation between
IPv4 and IPv6, but it is incomplete since it does not specify
how the packets with IPv4-translated IPv6 address to be
routed in the IPv6 network. These three mechanisms can be
thought as NAT-based mechanisms, so they have the inherent
NAT deficiencies. NAT-unfriendly applications can not pass
through the translator box without involvement of application
level gateways. At the same time, NAT-based mechanisms
also have the same demerit as proxy-based mechanisms as far
as the end-to-end communication is concerned. Further, any
solution based on NAT boxes is inefficient and not scalable.
DSTM[8] suggests a dual stack approach with dynamically
assigned IPv4 addresses and the use IPv4-over-IPv6 tunneling to help transition, but it only provides the limited
communication scenario and lacks flexibility since IPv6 hosts
have to obtain a tunnel endpoint address somehow before
setting up an IPv4-over-IPv6 tunnel.
In summary, DTTS is not a proxy-based nor NAT-based
mechanism, so it does not have such inherent weaknesses
mentioned before. DTTS is very similar to DSTM, but we
have not found a DSTM implementation. In addition, DTTS
hires dynamic tunneling technique, this makes it more
flexible and stable than DSTM.

management committee of SingAREN (http://www.singaren.

net.sg) project for supporting this work. We would also like
to thank Zit-Seng Lai and Budiman Tsjin for suggestions and
discussions.
REFERENCES
[1]
[2]
[3]

[4]
[5]
[6]
[7]
[8]

[9]

[10]

VI. CONCLUSION AND FUTURE WORK

In this paper, we have presented a new IPv4 to IPv6 transition solution called DTTS for achieving dual stack IPv6
nodes to communicate with IPv4 nodes in IPv4 network
using dynamic tunneling technique. Compared with other
related works, DTTS has several obvious advantages:
transparent end-to-end IP communication, scalable deployment, and most importantly, running of IPv4 applications in
an IPv6 environment seamlessly. We have implemented a
prototype system and tested its functions in our IPv6 testbed.
We believe DTTS as an IPv4 to IPv6 transition solution has
great potential to speed up IPv6 deployment. We plan to port
DTTS to other OSs like Windows and Solaris and to add
system security mechanism into public IPv4 address application and allocation process.
ACKNOWLEDGMENT

[11]
[12]
[13]
[14]

[15]
[16]
[17]

[18]
[19]

The authors would like to acknowledge the School of

Computing, National University of Singapore, and the

253

S. Deering, R. Hinden, Internet protocol, version 6 (IPv6)

specification, RFC2460, December 1998.
R. Gilligan, E. Nordmark, Transition mechanisms for IPv6 hosts
and routers, RFC2893, August 2000.
H. Kitamura, A. Jinzaki, S. Kobayashi, A SOCKS-based
IPv6/IPv4 gateway mechanism, Internet Draft(draft-ietf-ngtranssocks-gateway-06.txt).
J. Hagino, K. Yamamoto, An IPv6-to-IPv4 transport relay
translator, Internet Draft (draft-ietf-ngtrans-tcpudp-relay-01.txt).
E. Nordmark, Stateless IP/ICMP translation algorithm (SIIT),
RFC2675, February 2000
G. Tsirtsis, P. Srisuresh, Network address translation - protocol
translation (NAT-PT), RFC2766, February 2000.
K. Tsuchiya, H. Higuhi, Y. Atarashi, Dual stack hosts using the
Bump-In-the-Stack: technique (BIS), RFC2767, February 2000.
Jim Bound, Laurent Toutain, Hossam Afifi, Francis Dupont,
Alain Durand, Dual stack transition mechanism (DSTM), Internet Draft (draft-ietf-ngtrans-dstm-04.txt).
Y. Rekhter, B.Moskowitz, D. Karrenberg, G. J. de Groot, E. Lear,
Address allocation for private internets, RFC1918, February
1996.
R. Hinden, S. Deering, IP version 6 addressing architecture,
RFC2373, July 1998
S. Thomson, T. Narten, IPv6 statelesss address autoconfiguration, RFC2462 , December 1998.
S. Thomson, C. Huitema, DNS extensions to support IP version
6, RFC1886, December 1995.
M. Crawford, C. Huitema, DNS extensions to support IPv6
address aggregation and renumbering, RFC2874, July 2000.
A. Conta, S.Deering, Internet control message protocol
(ICMPv6) for the internet protocol version 6 (IPv6) specification, RFC2463, December, 1998.
Conta, S. Deering, Generic packet tunneling in IPv6 specification, RFC2473, December 1998.
P. Srisuresh, M, Holdrege, IP network address translator(NAT)
terminology and condiderations, RFC2663, August 1999.
I. Guardini, Migrating from IPv4 to IPv6: planning an effective
IPv6
transition,
May 2000,
http://carmen.cselt.it/papers
/globalIPsummit-v6trans/ipv6-transition-summary.html.
IETF
Next
Generation
Transition
working
group,
http://www.ietf.org/html.charters/ipngwg-charter.html.
P. Srisuresh, G. Tsirtsis, P. Akkiraju, A. Heffernan, DNS
extensions to network address translators (DNS_ALG),
RFC2694, September 1999.