Download Abstract: The Internet Engineering Task force began an effort to

Transition of Ipv4 to Ipv6
By
Anita Kanuganti
Hemanth Rao
Under The Able
Guidance Of
Professor
Dr.Mohamed Khalil
1
---------------------------------------------------Abstract: The Internet Engineering Task force
began an effort to develop a successor to the IPv4
protocol. A prime motivation for this effort was the
realization that the 32-bit IP address space was
beginning to be used up, with new networks and IP
nodes being attached to the internet(and being
allocated unique IP addresses) at a breathtaking
rate. To respond to this need for a large IP address
space, a new IP protocol was developed. But as the
saying goes, that every action has a equal and
opposite reaction, this solution lead to a more
serious problem, of how to make this transition of
changing all the IPv4 enabled nodes into IPv6
enabled nodes.
The different methods in which these transitions
can be implemented is the main point of discussion
in this paper. We will discuss all the methods and
their respective advantages and disadvantages. We
will also give a brief description of the IPv6
Protocol.
I. Introduction
The format of the IPv6 packet is shown in the
below described figure.
Version
Payload
Traffic
Class
Flow label
Next Hdr
Hop limit
Source Address
(128 bits)
Destination Address
(128 bits)
Data
Expanded addressing capabilities: IPv6
increases the size of the IP address from 32
---------------------------------------------------to bits to 128 bits. In addition to unicast
and multicast address, it also implements a
new type of address called the any cast
address. This allows a packet addressed to
an any cast address to be delivered to any
one of group of hosts. The IPv6 datagram
has the following fields defined.
1. Version This four bit field identifies
the IP version number. The IPv6
carries a value of “6” in this field.
Note that putting a “4” in this field
does not create a valid IPv4
datagram.
2. Traffic Class The eight-bit field is
similar in spirit to the ToS field that
we saw in the IPv4
3. Flow label This 20 bit field is used
to identify a “flow” of data grams
4. Payload length This 16 bit value is
treated as an unsigned integer
giving the number of bytes in the
IPv6 data grams following the fixed
length, 40 byte packet header.
5. Next header This field identifies the
protocol to which the contents (data
field) of this datagram will be
delivered. The field uses the same
value as the protocol field in the
IPv4 header.
6. Hop limit The contents of this field
are decremented by one by each
router that forwards the datagram. If
the hop limit count reaches zero, the
datagram is discarded.
7. Source destination address The
various formats of the IPv6 128 bit
address
8. Data This is the payload portion of
the IPv6 datagram.
There is also a new ICMP for IPv6. The
ICMP message is used by IP nodes to
report error conditions and provide limited
information for the end system. A new
version of the ICMP has been developed
2
for IPv6. This is discussed in the RFC
2463. In addition to reorganizing the
existing ICMP type and code definitions,
ICMPv6 also added new types and codes
required by the new IPv6 functionality.
These include the “Packet too big” type and
many more.
II. Requirements for Smooth Transitions
When we talk about the transition from
IPv4 to IPv6, we have to take into
consideration every component in the
network.
What we exactly mean here is that, every
node, every router in the network must be
made IPv6 compatible. But that does not
mean that they will be losing their IPv4
datagram processing capabilities.
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 IPng 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.
Constraints for the Transition:
Step wise transition: We are already aware
of that 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,
small-scale 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
Coexistence and internetworking: 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 IPngbased 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.
Feasible address mapping scheme: IPng
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.
Smart management tools: During the
transition and existence of dual protocol
networks the demand for a whole set of
management tools is clear. The new tools
must be clever enough to separate IPv4 and
IPv6 characteristics on multiple levels.
Detection of different routes and possible
translation points must be implemented. A
mechanism for checking the IPng
3
capability of remote hosts and devices is
essential. Without appropriate management
applications the complexity of a dual
protocol network will become a nightmare.
III. Transition Components
Hosts: In practice the concept of stepwise
transition means that for many years the
global Internet contains both hosts
restricted to traditional IPv4 operation and
hosts equipped with IPv6 capability. To
allow seamless interoperation, all hosts
running IPng must still be able to
communicate with the older technology. On
the application level software designed for
IPv4 uses the older API while new IPng
applications use the new API. Thus the
application actually knows which protocol
suite it is using. The IPv4 API and standard
applications should be available on IPv6
hosts as well if interoperation with common
tools (e.g. FTP, Telnet) is expected with
older IPv4 hosts.
Routers and routing protocols: From the
protocol version support point of view of
the routers must follow the same rules as
individual hosts. New devices with IPng
capability cannot assume that all other
systems they are interacting with are
equipped with the latest protocol support.
The compatibility constraint applies to
routing protocols as well. While
commercial issues gain more and more
interest within the Internet infrastructure,
IPng routing procedures must allow routing
based on traffic source and destination in
detail. Especially policy routing and
accounting are necessary for funding
agencies.
Domain Name System: During the
transition phase the new IPng capable hosts
have both a 32-bit IPv4 address and a 128bit IPv6 address. Old systems not upgraded
yet naturally have an IPv4 address.
However, an IPv6 address may already
have been assigned to them as well. DNS
has to reply with both addresses, if
available, for queries from IPng hosts. It is
then the decision of the communicating
host to select which protocol to use. For
old-fashioned queries from IPv4-only hosts
the response is the IPv4 address only. A
special condition arises when an IPv6
address has been attributed to a specific
host in DNS, but the host is not really IPng
capable yet. This is called a black hole in
the IPng address space and the associated
protocol software on communicating hosts
must handle such exceptions in an
acceptable way.
Component
Dependencies:
The
dependencies apply to the order of
transition of different network components,
the less resistance and delays are faced.
DNS servers are the first physical devices
to upgrade after a suitable IPng address
allocation and mapping scheme is
available. This allows new IPv6 hosts to
perform name service lookups for IPv6
addresses. Furthermore, the order of
migration on host and router software is
less critical. The concept of protocol
dualism allows IPv4 systems to continue
their operation without any modifications.
The changes in routing protocols can also
be performed with no hurry as the number
of IPng capable routers increases.
IV. Transition Techniques
During the years of transition, we can have
three different types of IP nodes, depending
on their capabilities, to support different
protocols.
1. IPv4 only node: A host or router
that implements only IPv4. An
IPv4-only node does not understand
IPv6. The installed base of IPv4
hosts and routers existing before the
transition begins are IPv4-only
nodes.
4
2. IPv6/IPv4 node: A host or router
that implements both IPv4 and
IPv6.
3. IPv6 node only: A host or router
that implements IPv6 and does not
implement IPv4. These are not
feasible for general purpose Internet
use until the transition has
proceeded into a phase where most
of the communities have upgraded
to IPng.
Simplified addressing mapping: One of the
major constraints set for the transition
process was the alternative for simple and
straightforward
IPv4-to-IPv6
address
mapping. This is performed by placing the
32-bit IPv4 address to the rightmost four
bytes of the 128-bit IPv6 address and
substituting a fixed site-specific or global
prefix to the remaining 96 bits.
For automated protocol compatibility
mechanisms
like
IPv6
in
IPv4
encapsulation (tunneling), a special prefix
of all zeros has been reserved. This is
called an IPv4 compatible address. The rest
of the IPv6 address space is reserved for
pure IPng addresses, termed IPv6-only
addresses. However, direct mapping of
IPv4 addresses may still occur using
service provider specific prefixes. This is
mainly to help the configuration and
administration of the address dualism in
user organizations
Dual IP layer: The most straightforward
procedure to satisfy the requirement for full
intersystem compatibility is to include a
complete IPv4 implementation to new IPv6
systems. This is what we call an IPv6/IPv4
node. They are able to transmit both IPv4
and IPv6 packets and thus interact with all
IP systems in the network. When combined
with protocol encapsulation, interaction of
IPv6 applications will be possible between
two IPv6/IPv4 nodes, even if the devices on
the route have not yet been upgraded to
IPng. The dual stack approach does not
necessary imply that the system should
contain
two
separate
protocol
implementations. It just should act as if it
did. From the application point of view
there are still two separate APIs and the
true decision whether IPv4 or IPv6 is used
is made on the application level
As shown in the below diagram, we have
six nodes, out of which A,B,E,F are IPv6
enabled and C,D are IPv4 are enabled.
A
B
F
C
D
E
We see, in this diagram the disadvantages
of the Dual stack approach, assuming that
node A wants to communicate with the
node F. Node A creates a IPv6 datagram
and transmits it to the next node that is
Node B, which is also IPv6 capable.
However node B must create an IPv4
5
datagram to send to node C. Here the data
field of the IPv6 packet can be copied into
the data field of the IPv4 datagram, and
appropriate address mapping can be done.
However, in performing the conversion
from IPv6 to IPv4, there will be IPv6specific fields in the IPv6 datagram that
have no counterpart in IPv4.The
information in these fields will be lost, and
hence the data will be lost.
Protocol Encapsulation/ Tunneling: During
the deployment of IPv6 the construction of
the new IPng compliant routing
infrastructure will take time. It would be an
intolerable limitation if IPv6 hosts on the
different edges of the network cannot
interoperate using IPng capabilities until all
intermediate routers are upgraded. This
issue can be solved using a technique called
IPv6-in-IPv4 encapsulation or IPv6-overIPv4 tunneling. Tunneling of IPv6 data
grams takes place by encapsulating them
within IPv4 packets. This way IPv6/IPv4
hosts and routers can tunnel IPv6 traffic
over regions of IPv4 routing topology. In
the simplest form the encapsulating node
adds an IPv4 header to the packet and
transmits it. The decapsulating node
removes the IPv4 header and processes the
remaining IPv6 packet as if it were
normally received via IPv6 topologies. In
practice the mechanism is not this simple.
The tunneling procedures must handle
several special conditions properly.
Physical View:
IPv6
IPv6
IPv4
IPv6
IPv4
Logical View:
IPv6
IPv6
IPv6
IPv4 tunnel
1. Fragmentation to several data grams
when the original IPv6 packet is too
big to fit into the data area of a
resulting
IPv4
packet.
The
discovery of optimal MTU sizes for
the path may be used to minimize
the fragmentation process.
2. Implementation of proper hop limits
(TTL). By default, the IPv6-overIPv4 tunnel, regardless how long it
actually is, is seen as a single hop
on the route from the IPv6 point of
view. The TTL values to
encapsulating IPv4 headers must be
set in an implementation dependent
manner.
3. Handling of IPv4 ICMP errors. If
IPv4 ICMP errors are detected
inside the tunnel path, special
mechanisms may be necessary to
6
pass the error information back to
the original initiator.
Two different types of tunneling may
occur. In configured tunneling the tunnel
path endpoint IPv4 address is defined in the
configuration of the encapsulating node.
This approach does not require any
interdependency between IPv4 and IPv6
addresses but requires a lot of effort to
manage. In automatic tunneling the tunnel
endpoint address is directly translated from
the original destination IPv6 address. The
IPv6 addresses used must be IPv4compatible addresses.
DNS "AAAA" records: A new DNS
resource record type named "AAAA" is
used for 128-bit IPv6 addresses. For
IPv6/IPv4 nodes the name service must
also contain the traditional 32-bit IPv4 "A"
record. The resolver libraries will then
retrieve the address that is actually
requested by the application (using IPv4 or
IPv6 API). For IPv4-compatible IPv6
addresses it is not necessary to respond to
queries with both "AAAA" and "A" records
if the IPv6 resolver library is able to extract
the IPv4 address directly from the 128-bit
form.
IP header translation: A technical
alternative for the dual IP layer approach
presented above would be to use dynamic
header translation between IPv4 and IPv6
packets. However, the practical difficulties
seen in this concept have been considered
to be too big, and this alternative has been
abandoned by the IETF. Since IPng
functionality is richer than IPv4
functionality,
successful
translation
between the protocols without losing the
new advanced features is difficult without
complex
manual
configuration
of
interworking applications and translators.
The administration of translator units
would also be very impractical unless they
are completely automatic and constantly
aware of the transition state of other hosts
in the network.
Before I conclude, there is one more
important topic to be considered here, that
is how to migrate the applications that are
dependent on the IP transport layer
protocol.
Migrating the applications: A very large
number of existing applications using an IP
transport layer protocol, like TCP, have
been implemented over the years. The main
concern in all this software is that the
network addresses are handled in a very
low level form, in practice by assuming that
the IP host address length is the IPv4 fixed
32 bits and usually internally storing the
address in a 32-bit wide application
variable. Thus the immediate conclusion is
that an existing TCP/IP application cannot
directly address an IPv6-only host.
Socket API changes: The IPv4 socket API
structures are defined to contain a 32-bit
field for IP addresses. For IPv6 these
structures will definitely change. Should
major modifications to the application
source code occur, depends on the way the
program handles the addresses and
especially the variable syntax used for
allocating space for them. At the easiest
form the conversion could be a simple
recompilation using the new API structure
definitions. At the worst form a lot of code
must be changed, reviewed and debugged
to produce a properly functioning and
robust module. To avoid this kind of
massive software modification demands in
the future, a new, network protocol
independent transport layer specification in
being written.
Binary compatibility: In hosts equipped
with both IPv4 and IPv6 support the
preservation of existing IPv4 binaries is
expected. In practice this can be
implemented by running them over the
7
native IPv4 stack, or by automatically
converting the traffic to take place over
IPv6. The latter alternative still restricts the
functionality to the IPv4 features and may
encounter problems, for example, if manual
mapping of IPv6 addresses to addresses
used by the application is required.
V. Conclusion
It is clearly a challenge to release IPng in a
form that is rapidly and commonly
accepted by the large commercial user
organizations of Internet. The home users
and educational sites are not a problem.
The transition risk is small and the
technological perspective is often seen as
the primary factor for the decision. In an
ideal transition concept the pushing force
would be the technical advantage and new
features offered by IPng, not any
commonly decided timetable that is
justified by the termination of support for
the older technology, the IPv4.
The transition techniques specified by the
IETF so far satisfy the general requirements
rather well. The represented scheme is easy
to adopt. The main areas of improvement
are in the configuration and administration
tasks which may get complicated during the
transition phase protocol dualism.
One important lesson that we can learn
from the IPv6 experience is that it is
enormously difficult to change network
layer protocols. Since the early 1990’s,
numerous new layer protocols have been
trumpeted as the next major revolution for
the Internet, but most of these protocols
have had limited penetration to date.
Indeed, introducing new protocols into the
network
layer is like replacing the
foundation of a house-it is difficult to do
without tearing the whole house down or at
least temporarily relocating the residents of
the House.
8
9