An Examination of IPv4 and IPv6 Networks :
Constraints and Various Transition Mechanisms
Jivika Govil1, Jivesh Govil2, Navkeerat Kaur3 , Harkeerat Kaur4,
Department of : Information Technology1, Electrical Engineering2,
Computer Science & Engineering3, Electronics & Communication4,
Maharshi Dayanand University1, University of Michigan2, GGS Indraprastha University3&4,
jivikag@email.com, jivesh@umich.edu, navkeeratkaur@yahoo.com kaurharkeerat@gmail.com
Abstract- The concept of transiting from IPv4 network to
IPv6 network is being processed vigorously. Extensive study is
being done presently on this subject as transition from IPv4 to
IPv6 requires a high level compatibility and clear procedure for
easy and independent deployment of IPv6. The transition
between IPv4 internet and IPv6 will be a long process as they are
two completely separate protocols. IPv6 is not backward
compatible with IPv4, and IPv4 hosts and routers will not be able
to deal directly with IPv6 traffic and vice-versa. In fact that there
will be extreme difficulties with address allocation and routing if
the internet is to continue to run indefinitely using IPv4. Also it
is impossible to switch the entire internet over to IPv6 over night.
As IPv4 and IPv6 will co-exist for a long time, this requires the
transition and inter-operation mechanism. Due to this reason
several transitions mechanisms have been developed that can be
used to make the transition to IPv6 smoothly. Most applications
today support IPv4 and thus there is a need to run these
applications on IPv6 access network, especially to persons who
are generally on mobile and they want to securely connect to
their home network so as to reach IPv4 services. This paper
discusses constraints, various techniques and standards require
for high level compatibility smooth transition and interoperation
between IPv4 and IPv6 by removing the constraints.
I.
with advantages, constraints and various transitions
mechanisms from IPv4 to IPv6.
II. IPV6 OVERVIEW
IPv6 was designed to be an evolutionary step from IPv4.
It was not a design goal to take a radical step away from
IPv4 [3]. Functions that work in IPv4 were maintained in
IPv6, and those that didn't work were removed..
A. IPv6 Features and Benefits
IPv6 was designed to build on the existing features of
IPv4 and provide new services and capabilities. Listed
below is an overview of several features and benefits IPv6 is
intended to provide.
1) Larger Address Space – IPv6 increases the IP address
size from 32 bits to 128 bits. Increasing the size of the
address field increases number of unique IP addresses from
approximately 4,300,000,000 (4.3×10^9) to 340,282,366,
920,
38,463,463,374,607,431,768,211,456(3.4×10^38).
Increasing the address space to 128 bits provides the
following additional potential benefits :
a) Enhanced Applications Functionality – Simplifies direct
peer-to-peer applications and networking by providing a
unique address to each device.
b) End-toEnd Transparency – The increased number of
available addresses reduce the need to use address
translation technologies
c) Header Format Simplification - Some IPv4 header fields
have been dropped or made optional, to reduce the commoncase processing cost of packet handling and to keep the
bandwidth cost of the IPv6 header as low as possible,
despite the increased size of the addresses. Even though the
IPv6 addresses are four times longer than the IPv4 addresses,
the IPv6 header is only twice the size of the IPv4 header.
d) Hierarchical Addressing – The hierarchical addressing
scheme provides for address summarization and aggregation.
These approaches simplify routing and manage routing table
growth.
e) Auto-Configuration – Users using IPv4 addresses use the
Dynamic Host Configuration Protocol (DHCP) server to
establish an address each time they log into a network. This
address assignment process is called stateful autoconfiguration. IPv6 supports a revised DHCPv6 protocol
that supports stateful auto-configuration, and supports
stateless auto-configuration of nodes. Stateless autoconfiguration does not require a DHCP server to obtain
addresses.
Stateless auto-configuration uses router
advertisements to create a unique address. This creates a
INTRODUCTION
Presently approximately 25 billion people are connected
to the internet Computer networks through internet are
connected worldwide and these networks are connected
through routers. The task of routers is to send data between
the different networks. The router together with an
addressing system and transport protocol called the internet
protocol IPv4 and provides a communication path between
any pair of hosts. Due to paucity of address space and
allocation mechanism i.e. used to allocate addresses in the
internet protocol, some parts of the world are beginning to
run out of addresses. A new version of internet protocol
called IPv6 has been defined so as to solve the address and
other problems in the currently used internet protocol. Also
currently IPv4 network is suitable for stationary users, the
only internet access available to mobile customer through
cellular phone services running on IPv6 [1]. Implementing
the transition and interoperation between IPv4 and IPv6
requires a easy process to adopt the deployment of IPv6
smoothly as Mobile IP cannot deliver IPv4 mobility from
IPv6 access network. To deliver this it requires huge
unnecessary investment in IPv6 infrastructure. Also we
cannot move from IPv4 to IPv6 straightaway and we require
developing a mechanism so that IPv4 and IPv6 exist
together for atleast 20 years and during transition period
IPv4 network will totally disappear [2]. This paper deals
978-1-4244-1884-8/08/$25.00 ©2008 IEEE
178
“plug-and-play”
environment,
simplifying
address
management and administration.
IPv6 also allows
automatic address configuration and reconfiguration. This
capability allows administrators to re-number network
addresses without accessing all clients. Fig. – 1 illustrates
the below
forward transition plan cannot work with the current IPv6
specification.
2) Incoherence: The IPv6 designers don’t have a transition
plan and due to this reason IPv4/IPv6 network has become a
complex issue. Without coherent transition plan, IPv6 has
no credibility. They should have designed the plan that if
implemented and universally deployed will produce the
magic result.
3) Distractions: Presently IPv6 address is not useful as it
cannot talk to IPv4 address. If we want IPv6 to succeed as
global network, we have to figure out how to make an IPv6
address just as useful as an IPv4 address . System needs to
configure that every Internet computer becomes
automatically enable to talk to IPv6 address. This cannot be
done overnight and it is the crux of the IPv6 transition.
4) Stepwise Transition: As the transition cycle will take
years and there is no way to synchronize the process on
different sites. A distributed approach is necessary.
Presumably only the smallest user organizations are able to
switch over to IPv6 in a single step. All others must be able
to make their own staged transition plan, and proceed in it
with as few interdependencies as possible. IPv4 and IPv6
network equipment must be allowed to coexist and
interoperate. It should even be realized that some old, smallscale systems may never be capable of running IPv6 . They
will maintain the old protocol suite in the network to the end
of the old hardware usage time.
5) Coexistence and Internet Working: The transition
independency means that the order of migration on unique
computers and network devices is not tied to the upgrade of
some other systems in the network. The release dates of new
computer systems, routers and application software cannot
be commonly synchronized. Old equipment and software
will be used in the network while the IPv6 based systems
and applications are deployed. The old systems should run
without modifications and be able to communicate with both
the old and new systems. In practice this means a strict
requirement for simultaneous support for both IPv4 and
IPv6 on all new systems.
6) Feasible Address Mapping Scheme: As discussed above
IPv6 brings the advantage of a very large address space
where even multiple addresses can be easily reserved for
each host. In addition to the complex scheme of 128-bit
IPv6 address distribution, a simplified method is necessary.
To make the transition process easier an optional simple
mapping from an old IPv4 address is desirable . Since it is
not possible to assume that all IPv4 addresses used are
globally unique, the mapping may be site-specific in some
cases instead of a fixed prefix.
7) IPv6 Standards and Product Evolution: Today, IPv6
technology is still evolving and this evolution is likely to
continue through the federal transition period. This is as
expected and is a normal evolution of the Internet standards.
While the base set of IPv6 protocols are stable and mature,
and product implementations are emerging, many of the
standards supporting value-added IPv6 features are still
evolving.
Therefore, developers/organizations to be
encouraged to ensure the IPv6 capabilities being procured
have a viable upgrade path.
.
Figure - 1 Auto Configuration
2) Scalability of Multicast Routing – IPv6 provides a much
larger pool of multicast addresses with multiple scoping
options.
3) Built in Security - Apart from the huge address, the IPv6
Internet Protocol version comes with built-in security of the
source.
4) Quality-of-Service Capabilities-A new capability is added
to enable the labeling of packets belonging to particular
traffic "flows" for which the sender requests special
handling, such as non-default quality of service or "realtime" service [4]. The phone conversations over the Internet
will be smooth and clear instead of choppy and broken up
like they often are now.
5) Improved Support for Options--Changes in the way IP
header options are encoded allows for more efficient
forwarding, less stringent limits on the length of options,
and greater flexibility for introducing new options in the
future.
6) Authentication and Privacy Capabilities--IPv6 includes
the definition of extensions, which provide support for
authentication, data integrity, and confidentiality]. This is
included as a basic element of IPv6 and will be included in
all implementations.
III. CONSTRAINTS OF TRANSITION PLANS FROM
IPV4 TO IPV6
The actual transition process from IPv4 to IPv6 can be
compared to the migration processes of smaller scale that
take place all the time. Operating system and software
development environment version changes are good
examples of such migration. The main constraints set for the
IPv6 transition should be generally the same as in any
smaller scale migration. However, for the global Internet
community the fulfillment of the constraints is much more
important, and few shortcuts can be tolerated [5].
Followings are some of the constraints listed.
1) Incompatibility: The IPv6 designers made a fundamental
conceptual mistake by designing the IPv6 address space as
an alternative to the IPv4 address space, rather than an
extension to the IPv4 address space. Hence a straight
179
IV. TRANSITION MECHANISMS AND INTEROPERATION
bridges etc will need to be able to deal with both protocols,
maintain double routing tables, etc. [8] Simplicity of routing
is supposed to be a strength of IPv6, if this sort of transition
mechanism were used it would become a weakness. To get
around these two problems, some mechanisms have been
developed which are discussed in following paras B to F.
These can be used in situations where a network has been
completely converted to IPv6, but which still needs to
communicate with the outside IPv4 world. They all rely on
various servers or devices that sit between the IPv6 and IPv4
networks doing some form of translation. Fig. – 3 illustrates
a typical dual IP Stack.
IPv6 is not backwards compatible with current internet
protocol and thus it is hard to deploy as old applications will
no longer work [6]. During the transition period, IPv6 nodes
are going to need to communicate with IPv4 nodes and
isolated “Islands of IPv6 installations” are going to need to
use the wider IPv4 network to connect to each other [7]. A
number of transition mechanisms have been defined and
following is a brief over view of some of transition
mechanism. Fig. – 2 illustrates the broadview of different
transition mechanisms.
B. Dual Stack Application Level Gateway (Dual Stack ALG)
Dual Stack ALG is an IP device running dual-stack and
can have access to both IPv4 and IPv6 services natively.
Dual-stack servers are used as proxies to perform protocol
translation with one proxy server per application (http, ftp,
smtp, etc). This has the advantage that very few IPv4
addresses are required (they are only needed for the proxies),
and the protocol translation step may not be such a large
price to pay in situations where firewalls and proxy server
already exist, which is the case in many LANs. However,
the disadvantage is that Dual Stack ALG’s are not able to
handle all services, particularly those that have pure end-toend requirements.
C. Network Address Translation
- Protocol Translator
(NAT-PT)
NAT-PT is a dedicated hardware device residing within
an IP router, situated at the boundary of an IPv4 network
and an IPv6 network. By installing NAT-PT between an
IPv4 and IPv6 network, all IPv4 users are given access to
the IPv6 network without modification in the local IPv4hosts (and vice versa). Equally, all hosts on the IPv6
network are given access to the IPv4 hosts without
modification to the local IPv6-hosts. Further as NAT-PT
device retains a pool of globally routable IPv4 addresses,
which are used to assign to IPv6 nodes on a dynamic basis
as sessions are initiated across the IPv6/IPv4 boundary.
Figure – 2 Transition Mechanisms
A. Dual IP Stacks
Nodes with dual IP stacks will have both IPv4 protocol
stack and an IPv6 one. When communicating with IPv6
nodes, they use IPv6 and when communicating with IPv4
nodes, they revert to IPv4. These nodes have IPv4
compatible IPv6 addresses - these are addresses where the
first 96 bits of the address are zeroes and the last 32 forms a
valid IPv4 address. Every current IPv4 address can be
transformed to an IPv6 address in this fashion.
Consequently, this requires all dual-stack nodes to have
IPv4 addresses. This may not be feasible considering that
one of the major reasons for transitioning to IPv6 is that the
available address space is set to run out. This approach is
inefficient for routers.
Figure – 4 Network Address Translation.
In addition to address translation, header translation is
performed as described in the SIIT mechanism (SIIT). As
opposed to SIIT, which is a stateless translation mechanism,
NAT-PT retains state via the IPv4 to IPV6 address
mappings which are retained for the duration of each session.
NAT-PT can be extended to NAPT-PT (Network Address
Port Translation – Protocol Translation). NAPT-PT takes
the address translation a stage further by enabling the
translation of port numbers as well. This makes it possible
to re-use one IPv4 pool address and map this one IPv4
address to many IPv5 hosts [9]. The basic NAT-PT
Figure – 3 Dual IP Stacks
Consider a LAN where all hosts are IPv6 enabled, but are
running dual IP stacks to communicate with the outside
world. The entire network infrastructure, i.e. routers and
180
F. Dual Stack Transition Mechanism, or DSTM
Dual Stack host have both IPv4 and IPv6 interfaces
configure and can communicate with both IPv4 and IPv6
hosts. DSTM is an IPv4 to IPv6 transition proposal based on
the use of IPv4 over IPv6 dynamic tunnels and the
temporary allocation of IPv4 global addresses to Dual-Stack
hosts. - DSTM is intended for IPv6-only networks in which
hosts still need to exchange information with other IPv4
hosts or applications.
translation device may additionally contain ALG’s
(Application Level Gateways). ALG’s are necessary when
IP addresses are embedded within the payload of an IP
packet. For normal packet translation. NAT-PT would not
look within the payload for IP addresses. Typical protocols
that embedded IP addresses in the payload are FTP and
DNS. NAT-PT requires no special configuration on the
client, apart from using the correct DNS server which can
be configured automatically through DHCPv6 for example.
D. Network Address Port Translation – Protocol Translation
(NAPT-PT)
A large number of users, offices and telecommuting
employees have multiple network nodes in their office.
These are running TCP and UDP applications, but have a
single IP address assigned to their remote access router by
their service provider to access remote networks. The
increasing number of remote access users would be gained
by NAPT-PT, which allows multiple nodes in a local
network, at the same time access remote networks using the
single IP address assigned to their router.
NAPT-PT is a special case of dynamic NAT and NAPTPT uses port numbers as the basics for the address
translation. With NAPT-PT, IPv6 nodes are allowed to
communicate with the IPv4 nodes transparently using a
single IPv4 address. The TCP and the UDP ports of the IPv6
nodes are translated into the TCP and the UDP ports of the
registered IPv4 addresses. This allows the TCP and the UDP
ports of a number of private hosts to be multiplexed into the
TCP and the UDP ports of a single external address. A pool
of external addresses is used when port translation is made
under NAPT-PT. The number of ports available, that is 216
= 65536, limits the number of connections per IP address.
Many ports are assigned to specific services and ports up to
number 1024 are well known ports.
NAPT-PT translates the source IP address, source TCP
port, source UDP port and related fields such as IP, TCP,
UDP and ICMP header checksums, for packets outbound
from the private network. The destination IP address,
destination TCP port, destination UDP port and the IP, TCP
and UDP header checksums are translated, for inbound
packets .
NAPT-PT solves the problem, which NAT would not be
able to handle, when the pool of IPv4 addresses assigned for
the translation is exhausted which implicates those newer
IPv6 nodes will not be able to establish sessions with the
outside world anymore .
Performance
Scalability
Security
Cost/
Complexity
Transparent to
the application
No change to
legacy IPv4
application
Easy
Manageability
No Protocol
Translation
Dynamic
Allocation of
IPv4 address
Based on
Standard
Protocols
Security
E. Stateless IP/ICMP Translator (SIIT)
SIIT (SIIT) is a transition mechanism algorithm that
translates between IPv4 and IPv6 packet headers, including
ICMP, in separate translator “boxes” in the network, without
requiring any per-connection state in those “boxes”. This
algorithm can be used as a part of a solution that allows
IPv6 hosts, which do not have a permanently assigned IPv4
address, to communicate with IPv4 only hosts [10]. NATPT is an example of such a solution. the RFC neither
specifics how to do address assignment nor routing to and
from the IPv6 hosts when they communicate with IPv4 only
hosts.
TABLE I
PARAMETERS IN CONCERN FOR DSTM
Tunnel at DSTM host on IPv6 domain allows for
high scalability of IPv6-end TEP.
Pays tunneling overhead of at least 40 bytes per
IPv4 packet due to v4 in v6 overhead.
Since interoperability is at the edge, this is highly
scalable on V6 network.
Native IPv6 address prefix allows global routing
scalability.
Good, but tunnel brokered DSTM adds even better
security
via
Authorization,
Authentication,
Accounting (AAA). to determine who can set up the
tunnel. ----Can use native IPv6 IPSEC only up to
IPv4 tunnel TEP. ---- Can use native IPv4 IPSEC.
Can be offered as an enterprise service with tunnel
broker & router in one box.
Requires client software on hosts, but this can be
distributed via DSTM tunnel broker.
To reduce cost/complexity can use a DHCPv6
server, tunnel broker, or static assigned IPv4
addresses in place of DSTM address server on IPv6
domain.
Administrators must set up DSTM, then tunnels can
be set up and torn down automatically as needed.
TABLE II
ADVANTAGES OF DSTM
All types of protocol/ applications can be forwarded
transparently and no changes are needed to
configure translators.
Each host in the dominant IPv6 network will be a
dual IPv4/IPv6 nodes, there are no changes required
for legacy IPv4 applications. All IPv4 traffic is
tunneled i.e. IPv4/IPv6, towards a DSTM Gateway.
DSTM maintains IPv6 only environment. No IPv4
routes needed. Hence easy to manage.
As DSTM uses IPv4/IPv6 tunneling for IPv4
communications. Hence the communication is
straight forward and simple.
Whenever a DSTM client sends a request to the
DSTM Server for a dynamic IPv4 address, it will be
reclaimed by the server even its life time has
expired. A DSTM server can serve the need of IPv4
address for a large number of IPv6 nodes by having
a small IPv4 address pool.
DSTM is based on Standard Protocol, hence not
complex.
DSTM transition mechanism is more secure as it
does not use NAT (Network Address Translation).
SSH (Secure Shell) and IPsec with IPv4/IPv6 can be
used without any modification.
The DSTM architecture is composed of an addresses
server, that can provides the assignment of IPv4 addresses to
IPv6 Nodes [11]. The server will also be used to maintain
the mapping between the allocated IPv4 address and the
permanent IPv6 address of the node. Each IPv6 DSTM will
have an IPv4 interface called the Dynamic Tunneling
Interface (DTI) designed to encapsulate IPv4 packets into
IPv6 packets. A DSTM client on the node should be used
for IPv4 address allocation and may be used to solve the
181
H. Dual Stack Mobile IPv6
The dual stack Mobile IPv6 draft provides IPv4
extensions to the Mobile IPv6 protocol . The extension
allow a node that has IPv4 and IPv6 addresses to roam
within the Internet using Mobile IPv6 only, while
simultaneously maintaining connections using their IPv4
and IPv6 home addresses[14]. When the mobile user is
located on a dual stack or IPv6 only access network, the
Mobile IPv6 signalling is sent over IPv6 to the Home Agent.
When the mobile user is located on an IPv4 only access
network, the Mobile IPv6 signalling packets are tunneled in
IPv4 to the Home Agent[15]. The drawback with the dual
stack Mobile IPv6 mechanism is that it does not handle
situations when only private IPv4 addresses are available in
the access network, which is a common situation.
mapping between IPv4 and IPv6 addresses. Table I
provides a discussion of various parameters in respect to
DSTM. Table- II highlights some of the advantages of
DSTM. Also the Fig. – 5 explains the Dual Stack Transition
Mechanism.
As DSTM technique provides a unique solution to the
IPv4-IPv6 transition problem. This mechanism is designed
to rapidly reduce the reliance on IPv4 routing and is
intended for IPv6-only networks in which hosts still
occasionally need to exchange information directly with
other IPv4 hosts or applications. Network administration is
simplified and the need of IPv4 global addresses is reduced
[12].
I.
IPv6 over Mobile IPv4
IPv6 over Mobile IPv4 specifies a Mobile IPv4 extension
that may be used by dual stack mobile nodes to obtain IPv6
service with the use of a Mobile IPv4 registration. This
extension allows for immediate deployment of IPv6 on dual
stack mobile devices, without the need for a full IPv6
infrastructure. It is believed that providing IPv6 services to
mobile devices in the short term will spur the growth of
IPv6 networks [16]. The specification requires that the
mobile node and Home Agent have dual IPv4 and IPv6
stacks, but there are no changes to the Foreign Agent and it
does not need to be dual stack. Thus this mechanism with
MIPv6, will achieve IPv6 mobility from any network [17].
Figure – 5. Dual Stack Mechanism
DSTM can be integrated with an IPv6 Tunnel Broker for
tighter security integration. DSTM routers can be coupled
with IPv4 Firewalls and Intrusion Detection systems to
secure IPv4 tunnel endpoints from IPv4-based attacks. Dual
Stack Transition Method (DSTM) is different than the pure
Dual Stack running on a single host. Figure – 6 illustrates
the same.
J.
IPv6-over-IPv4 Tunneling
Tunneling is a mechanism that has been defined to allow
IPv6 packets to be encapsulated in IPv4 packets. A dual
stack hosts can send IPv6 packets through an IPv4 tunnel to
a remote IPv6 hosts without requiring an IPv6 infrastructure.
Tunneling is used to carry IPv6 packets across IPv4 routed
network areas. One of the requirements for tunneling is that
the begin and endpoints of the tunnel are IPv6/IPv4-nodes
with IPv4-compatible IPv6 addresses. Tunneling means that
the whole IPv6 packet is mapped into a body of an IPv4
packet and sent across the IPv4 network area. The endpoint
of the tunnel has to be either an IPv6/IPv4-headertranslating-router or an IPv6/IPv4-node to de-encapsulate
the packet [18]. The destination address of the new IPv4
packet is the address of the node representing the tunnel
endpoint. RFC 2893 defines the following tunneling
configurations with which to tunnel IPv6 traffic between
IPv6/IPv4 nodes over an IPv4 infrastructure: Router-toRouter, Host-to-Router or Router-to-Host, and Host-to-Host.
There are various types of tunneling.
Figure - 6. Transition IPv6 seamlessly in DSTM
G. Dual Stack Mobile IPv4
Dual Stack Mobile IPv4 draft provides IPv6 extensions to
the Mobile IPv4 protocol. The extensions allows a node
that has IPv4 and IPv6 addresses to maintain
communications with either or both of its addresses while
moving in IPv4 or dual stack networks. The specification
essentially separates the Mobile IP signaling version from
the IP version of the traffic that it tunnels [13]. Mobile IPv4
with these new extensions becomes a signalling protocol
that runs over IPv4, and yet can set-up any combination of
IPv4 and /or IPv6 over IPv4 tunnels. But when the user
moves to an IPv6 access network this cannot be used since
the signalling is sent over IPv4 only.
K. Configured Tunneling
Tunneling techniques are classified by way the
encapsulating node determines the address of the node at the
end of the tunnel. In router-to-router and host-to-router
tunneling methods, the IPv6 packet is tunneled to a router.
The tunnel endpoint is an intermediary router. The
intermediary router decapsulates the IPv6 packet, then
forwards it to its final destination. When tunneling to a
router, the tunnel endpoint differs from the tunneled
packet’s destination. So the addresses in the tunneled IPv6
182
packet do not provide the IPv4 address of the tunnel
endpoint. Instead, the node performing the tunneling
provides configuration information that determines the
tunnel endpoint address [19]. This type of tunneling is called
“configured tunneling.” (Fig. – 7)
host establishes the tunnel only when it needs to; the host is
also able to discover the tunnel destination (that is, the
router’s IPv4 address) dynamically through DNS or a local
definition. Because both IPv4 and tunneled IPv6 packets are
transported over a single common IPv4 infrastructure, IPv4dependent applications can continue to use IPv4 while
newer IPv6-capable applications can be deployed
immediately.
Figure -7 Configured Tunneling
L.
Automatic Tunneling
In the host-to-host and router-to-host tunneling methods,
the IPv6 packet is tunneled all the way to its final
destination. The tunnel endpoint is the node to which the
IPv6 packet is addressed. Because the tunnel endpoint is the
IPv6 packet’s destination, the IPv6 packet’s destination
address determines the tunnel endpoint: if that address is an
IPv4-compatible IPv6 address, then the low-order 32-bits
hold the destination node’s IPv4 address. That can be used
as the tunnel endpoint address. This technique avoids the
need to explicitly configure the tunnel endpoint address.
Deriving the tunnel endpoint address from the embedded
IPv4 address of the packet’s IPv6 address is called
“automatic tunneling.” (Fig. – 8)
Figure -9 ISATAP Tunnels
As a transition strategy, ISATAP is ideal for campus and
branch sites because ISATAP allows organizations to
activate IPv6 connectivity on the existing IPv4-only
network while the infrastructure is gradually migrated to
integrate native IPv6 capabilities. Thus, the immediate
effect on the IPv4 support infrastructure is reduced to the
configuration of one ISATAP router, but it is recommended
that at least two ISATAP routers to be deployed for high
availability. Additionally, because ISATAP allows native
IPv6 connectivity to be activated first in the backbone, other
parts of the IPv4 infrastructure can preserve their investment
as they naturally evolve to support IPv6.
Figure -8 Automatic Tunneling
M. ISATAP Tunnels
Intra-Site Automatic Tunnel Addressing Protocol
(ISATAP) is another tunneling technique (Fig. - 9). It
differs from manually configured tunneling in that ISATAP
tunnels are automatically defined rather than statically
defined. Also, ISATAP tunnels are primarily used between
hosts and routers, whereas manually configured tunnels are
used between routers. With ISATAP, a tunnel is created
from a host, such as a PC, to a router or Layer 3 switch. The
tunnel is established by using the IPv4 addresses of both the
host and the router. The tunnel is “automatic” in that the
Figure -10 An Example ISATAP Configuration
ISATAP islands can also be created to allow gradual
evolution to native IPv6 capabilities within different
parts of the organization without blocking end-to-end IPv6
service deployments. Although it has many benefits,
ISATAP does not support IPv6 multicast, so this would not
be the most appropriate transition strategy for organizations
requiring that capability. Fig. – 10 is an example of
183
ISATAP configuration and Fig. – 11 shows an ISATAP
Router.
The address of 6 to 4 gateway to use, to connect to the rest
of the IPv6 world. Fig. 12 shows a typical 6 to 4 site and
Fig. – 13 shows 6 to 4 components.
Figure -11 An ISATAP Router
N. 6 to 4
This is an IETF standard and specified in RFC 305. When
one IPv6 network connects to other IPv6 network this
mechanism is used because it connects IPv6 end–site
networks by automatic tunneling over the intervening IPv4
internet. A special IPv6 routing prefix is used to indicate
that the remaining 32-bits of the external routing prefix
contains the IPv4 end-point address of a boundary IPv6
router for the site, that will respond to IPv6 in IPv4
encapsulation. This will allow a host that is located behind
a 6 to 4 router to communicate the other 6 to 4 hosts on the
Internet. When the host sends an IPv6 packet to another 6 to
4 host, the packet is tunneled in IPv4 at the 6 to 4 router
using the IPv4 address contained in the prefix of the 6 to 4
destination address as the IPv4 destination address. At the
destination site the IPv4 header is removed at the 6 to 4
boundary router and forwarded to the appropriate 6 to 4 host
by using the IPv6 routing infrastructure of the destination
site [20]. In other words by using a 6 to 4 replay router, a 6
to 4 host can send IPv6 packets to a native IPv6 node on the
IPv6 Internet. The packets are encapsulated in IPv4 at the 6
to 4 router and sent to the IPv4 address of the configured 6
to 4 relay router.
Figure – 13. 6 to 4 components
O. 6 over 4
6 over 4, also known as IPv4 multicast tunneling, is a
host-to-host, host-to-router, and router-to-host automatic
tunneling technology that is used to provide unicast and
multicast IPv6 connectivity between IPv6 nodes across an
IPv4 intranet. 6 over 4 hosts use a valid 64-bit prefix for
unicast
addresses
and
the
interface
identifier :WWXX:YYZZ, where WWXX:YYZZ is the
colon-hexadecimal representation of the IPv4 address
(w.x.y.z) assigned to the host. By default, 6 over 4 hosts
automatically
configure
the
link-local
address
FE80::WWXX:YYZZ on each 6 over 4 interface.
6 over 4 treat an IPv4 infrastructure as a single link with
multicast capabilities. This means that Neighbor Discovery
processes (such as address resolution and router discovery)
work as they do over a physical link with multicast
capabilities. To emulate a multicast-capable link, the IPv4
infrastructure must be IPv4 multicast-enabled. IPv4
multicast is not generally available on all networks, and
there are scalability issues with this approach. It is ideal for
small self contained networks where multicasting is
available.
P. Bump-In-the-Stack (BIS) Mechanism
The BIS mechanism is for communication between IPv4
applications on an IPv4-only host and IPv6-only hosts. The
mechanism is a solution for users who cannot upgrade their
certain application for some reasons after all applications are
modified. So BIS is not a mechanism that is designated for
the initial stage in the transition from IPv4 to IPv6, but it’s
probably a mechanism that will be used in the future to
connect the ’old’-legacy IPv4 applications with the widely
use of IPv6 applications [21].
Three extra layers - name resolver extension, address
mapper, and translator - are added to the IPv4 protocol stack
between the application and network layers. Whenever an
application needs to communicate with an IPv6-only host,
the extra layers map an IPv6 address into the IPv4 address
of the IPv4 host.
BIS mechanism has some limitations. BIS performs the
translation of IPv4 packets to IPv6. This gives an IPv6 host
Figure – 12. 6 to 4 site
The relay router has native connectivity to the IPv4 and
IPv6 Internet. The 6 to 4 router removes the IPv4 header
and forwards the IPv6 packet to the appropriate IPv6
Internet host. So these two pieces of information are
required i.e. a) Outside visible address (this might be a
gateway or similar) from which we drive our IPv4 48 bit
prefix and then somehow choose the rest of the address. b)
184
the ability to use the translated IPv6 packets. The translation
cannot be applied to IPv4 applications, which use the IPv4
option header, since it is impossible to translate IPv4 option
headers to IPv6, and IPv6 option headers to IPv4 [22]. Only
fragmentation and routing headers have the exception to be
translated. Another limitation of BIS is that the extension
name resolver cannot handle the secure DNS protocol.
Further the BIS mechanism works only with unicast
communication, and does not support multicast
communication.
end-to-end security between the client and the gateway, and
the gateway and the destination. The mechanism uses a
feature called DNS Name Resolving Delegation to
determine IPv6 addresses, delegating the name resolving to
the gateway, thus requiring no change to existing DNSs.
V. CONCLUSION
IPv6 solves internet scaling challenges, provides flexible
transition mechanisms for the current internet, and meets the
needs of such new markets as mobile, personal computing
devices, network entertainment and device control. Thus we
must implement IPv6 as early as possible. Till today no
single best solution for transition plan is developed though
there are large set of IPv6 transition tools available. This
transition plans are likely to be site specific. We must gain
the experience in IPv6 operation as early as possible and
must work towards only adopting IPv6 networks.
Q. Bump-In-The-API (BIA) Mechanism
BIA Mechanism inserts an API Translator between the
socket API module and the TCP/IP module in the dual stack
hosts, to translate the IPv4 socket API function to IPv6
socket API function and vice versa. Thus transition is
simplified without IP header translation. When using BIA,
the dual stack host assumes that there exists both IPv4 and
IPv6 stacks on the local node. When an application on the
dual stack communicate with other IPv6 hosts, the API
translator detects the socket API functions from IPv4
applications and invokes the IPv6 socket. API functions to
communicate with the IPv6 hosts, and vice versa. In order to
support communication between IPv4 applications and the
target IPv6 hosts, pooled IPv4 addresses will be assigned
through the name resolver in the API translator.
REFERENCES
[1]
[2]
[3]
[4]
[5]
[6]
R. Transport Relay Translator (TRT)
The transport relay translator (TRT) mechanism functions
on the transport layer of the TCP/IP reference model. It
allows IPv6-only nodes to communicate with IPv4-only
nodes by translating TCP-over-IPv6 to TCP-over-IPv4, and
the other way round. The TRT mechanism works the same
for UDP traffic. The TRT system can be located on a dual
stack host or router. - When an initiating IPv6 host wants to
communicate with an IPv4 host it needs an IPv6 destination
address? All TCP traffic from the IPv6 host goes through
the TRT system, which functions as a traffic relay server.
When the TRT system receives incoming TCP traffic from
an IPv6 source host (X6) to an IPv4 destination host (Y4), it
makes an IPv6 connection with the initiating IPv6 host. The
TRT system is configured with a dummy IPv6 prefix like
C6::Y4/64, where Y4 is the destination IPv4 address. The
initiating IPv6 host has the ability to connect to the IPv4
host through the IPv6 address C6::Y4. After that, the relay
server makes a connection with the IPv4 host and forwards
the TCP traffic to the IPv4 host. When the relay server
receives traffic from the IPv4 host, it establish in the same
way a virtual connection with address C6::/64, and forwards
the traffic to the IPv6 host.
[7]
[8]
[9]
[10]
[11]
[12]
[13]
[14]
[15]
[16]
[17]
[18]
S.
SOCKS-Based IPv6/IPv4 Gateway
The SOCKS-based IPv6/IPv4 gateway mechanism is for
communication between IPv4-only and IPv6-only hosts. It
consists of additional functionality in both the end system
(client) and the dual-stack router (gateway) to permit a
communications environment that relays two terminated
IPv4 and IPv6 connections at the application layer. This
mechanism is based on the SOCKSv5 protocol, and inherits
all the features of that protocol. Existing SOCKSv5
commands are unchanged, and the protocol maintains the
[19]
[20]
[21]
[22]
185
C. Perkins, “IPv6 from the Viewpoint of Mobile Wireless,” The
COOK Report on Internet, Vol. IX No.11, February 2001.
WIDE project. SHISA, 2006. http://www.mobileip.jp/.
WIDE project, 2006. http://www.wide.ad.jp/.
Nautilus6 project. MonNemo: A NEMO Monitoring Application,
2006.http://software.nautilus6.org/.
Nautilus6 Project, 2006. http://www.nautilus6.org/.
“Interoperability
between
IPv4
and
IPv6.”
(http:/ntrg.cs.tcd.ie/undergrad/ 4ba2.02/ipv6/interop.html
K. K., Ettikan, et al. “Application Performance Analysis in Transition
Mechanism from IPv4 to IPv6,” Multimedia University (MMU),
Jalan Multimedia, June 2001.
S. Shepler, B. Callaghan, D. Robinson, R. Thurlow, C. Beame, M.
Eisler, D. Noveck, “Network File System Version 4 Protocol,” RFC
3530, April 2003.
G. Tsirtsis, P. Srisuresh, “Network Address Translation - Protocol
Translation (NAT-PT),” Internet Engineering Task Force, February
2000.
E.Nordmark, “Stateless IP/ICMP Translation Algorthism (SIIT),”
RFC 2765, February 2000.
V. Devarapalli, R. Wakikawa, A. Petrescu, and P. Thubert, “Network
Mobility (NEMO) Basic Support Protocol,” Technical Report
RFC3963, IETF, January 2005.
B. Carpentere K. Moore, “Connection of IPv6 Domains via IPv4
Clouds,” RFC3056, Feb. 2001.
G. Tsirtsis, H. Soliman, “Dual Stack Mobile IPv4,” draft.tsirtsisv4v6- mipv4-00 txt, August 2003.
H. Soliman, G. Tsirtsis, V. Deverapalli, J. Kempf, H. Levkowetz, P.
Thubert, and R. Wakikawa, “Dual Stack Mobile IPv6 (DSMIPv6) for
Hosts and Routers,” Technical Report draft-ietf-mip6-nemov4traversal-01, IETF, March 2006.
D. Johnson, C. Perkins, J. Arkko, “Mobility Support in IPv6,” draftietfmobileip- ipv6-24-txt. June 2003.
D.B. Green, “DoD IPv6 Standards Profiles for IPv6 Capable
Products,” Version 1, The First Thailand IPv6 summit May 2006.
http://www.tahilandipv6.net/ipv6summit/ en/home/index.html.
P. R. Calhoun, P. E. Engelstad, T. Hiller, P. J. McCann, “IPv6 over
Mobile IPv4,” draft-mecann-mobileip-ipvvmipv4-03.txt., October
2002.
L. David, Mills, “Network Time Protocol (Version 3) Specification,
Implementation and Analysis,” RFC 1305, March 2002.
A. Durand, P. Fasano, I. Guardini, D. Lento, “IPv6 Tunnel Broker,”
Internet Engineering Task Force, January 2001.
Jivesh Govil, Jivika Govil, “On the Investigation of Transactional and
Interoperability Issues between IPv4 and IPv6”, 2007 IEEE
Electro/Information Technology Conference, (EIT 2007) 17-20 May
2007, Chicago,USA
I. Raicu, “An Empirical Analysis of Internet Protocol version 6
(IPv6),” Master Thesis, Wayne State University, 2002.
S. Lee, M.K. Shin, Y.J. Kim, E. Nordmark, A. Dorant, “Dual Stack
Hosts Using Bump-in-the-API,” (BIA), RFC 3338, October 2002.