![](bg2.png)
time as IPv6 was proposed. However, such a trans-
lator is basically assuming to map one IPv4 address
to multiple IPv6 addresses, because its main usage
is to provide IPv4 connectivity to IPv6 only nodes
originally. This means the software tends to become
complicated because it has to keep track on the ad-
dress mapping status and session status among mul-
tiple IPv6 addresses. It also has a scalability and re-
dundancy problem because it needs to manage many
mapping information and session status and this status
information is hard to share and synchronize among
multiple translator nodes. Our proposed system par-
ticularly insists on one-to-one address mapping which
doesn’t have problems addressed above, with the as-
sumption that the translator is used as a part of an IaaS
system. With this compromise, we can design a real-
istic IaaS system without having problems of existing
IPv4-IPv6 translation system as described before and
realize IPv6-only backend service operation.
2 RELATED WORKS
2.1 IaaS Model
Needless to say, most of the current service providers
are using IPv4 as their base IP protocol to build ser-
vices. As IPv6 is getting popular, some of them are
now considering to supporting dual-stack service us-
ing translators. Although there are several transition
scenarios to move from IPv4 to IPv6 (Mackay et al.,
2003), they basically use IPv4 for server nodes and
provide IPv6 connectivity to IPv6 clients using trans-
lator technology. This is the biggest difference from
our approach. We use IPv6 addresses for server nodes
and provide dual stack connectivity to client nodes.
Considering that the IPv6 clients are going to grow in
the future, focusing on IPv6 and providing IPv4 as an
additional service seems the right choice.
The traditional translation operation is shown in
section 2.1 of Chen’s paper (Chen, 2011). We think
that the model has several drawbacks. First, since it
uses IPv4 for their backend service networks, it may
face the IPv4 depletion problem. Second, if they use
private IPv4 address space to avoid the IPv4 depletion
issue, they may face IPv4 NAT traversal issues for
servers they are operating in their private networks.
Third, if they use NAT for their servers, they have to
operate two NAT services, one for IPv4 private ad-
dresses, and the other for IPv6-IPv4 addresses. In our
proposed model, IPv6 services are provided natively,
and IPv4 services are provided using translation. De-
tailed discussion is provided in section 3.1.
2.2 Translators
Discussion to develop technologies to bridge IPv4
and IPv6 was started as early as when IPv6 protocol
designers decided not to provide IPv4 backward com-
patibility in IPv6. Waddington and Chang summa-
rized IPv4-IPv6 transition mechanisms in their paper
(Waddington and Chang, 2002). From the viewpoint
of translation mechanisms, we can classify these tran-
sition technologies into three approaches. The first
approach is providing interoperability in the applica-
tion layer, the second approach is relaying data in the
transport layer, and the last is converting an IP header
in the IP layer.
The first approach, the application layer approach
is performed by proxy server software designed for
each application protocol that needs interoperability
between IPv4 and IPv6. The proxy server will be
located at the boundary of IPv4 and IPv6 networks
and accept specific application requests (e.g. web re-
quests) from client nodes. The proxy server inter-
prets the request contents, build a new request for
the destination server, and send it using a proper IP
protocol. The response from the server node is inter-
cepted and resent by the proxy server as well. Since
the proxy server understands the application protocol
completely, this approach can be most flexible com-
pared to the other approaches. On the other hand, de-
velopment per application protocol is required which
will increase development and operation cost. This
approach is mostly used when we only need com-
plex context processing in between IPv4 and IPv6 net-
works, since many services can be interoperable using
the rest of the approaches.
In the second approach, the transport layer ap-
proach, the relay server located in between the IPv4
and IPv6 networks terminates incoming connections
from clients at the socket level, and starts new trans-
port connections to the destination server on the other
side of the network. The well-known mechanisms
of this approach are, for example, SOCKS64 (Ki-
tamura, 1999; Kitamura, 2001) and Transport Re-
lay Translator (itojun Hagino and Yamamoto, 2001).
In SOCKS64, the client side SOCKS64 library re-
places the DNS name resolution and socket I/O func-
tions to intercept all the client traffic and forward to a
SOCKS64 server. This mechanism requires client ap-
plications to be updated to use the SOCKS64 library,
however, once the library is replaced, applications do
not need to pay any attention to IPv4-IPv6 translation
issues. The Transport Relay Translator does not re-
quire any update to client applications. Instead, the
mechanism assumes that clients use specially crafted
IPv6 addresses in which IPv4 address of the server is
DESIGN,IMPLEMENTATION,ANDOPERATIONOFIPv6-ONLYIaaSSYSTEMWITHIPv4-IPv6TRANSLATOR
FORTRANSITIONTOWARDTHEFUTUREINTERNETDATACENTER
307