10 1 1 133 4437 PDF

A COMPARATIVE STUDY ON THE PERFORMANCE OF IPv4 AND IPv6
by
Mohammad Mokbul Ahmed
A Thesis Presented in Partial Fulfillment

of the Requirements for the Degree
Master of Science
in
Computer Science
INDEPENDENT UNIVERSITY, BANGLADESH

June 2006
A COMPARATIVE STUDY ON THE PERFORMANCE OF IPv4 AND IPv6

by
Mohammad Mokbul Ahmed
has been approved

May 2006
APPROVED:
Professor Dr. M. Abdus Sobhan,
, Chairperson
Professor Dr. M. Lutfar Rahman,
, Member
Dr. Indrani Haque,
, Member
Dr. Feroz Ahmed,
, Member
Supervisory Committee
ACCEPTED:
___________________________________________
Director
School of Engineering and Computer Science (SECS)
ABSTRACT
In this thesis, a comparative study on the performance analysis of IPv4 and IPv6
protocol stacks under Microsoft Windows 2003 Standard Server and Red Hat Linux
Enterprise version 4 in point-to-point and router-to-router architectures have been
done in terms of bandwidth utilization (throughput) for different data sizes, round trip
time (latency) computation and overhead variation calculation. Real-time experiments
have been carried out for the above-mentioned architectures in the laboratory. For
point-to-point architecture, two PCs were configured at IPv4 and IPv6 under the
Windows and Linux operating platforms respectively. For router-to-router
architecture, two PCs and two IPv4 and IPv6-enabled CISCO 2811 routers were
configured at IPv4 and IPv6 protocols under the same operating platforms
respectively.
From the experimental results, we find that IPv6 incurs around 1 to 5% and 9 to 20%
more overhead in point-to-point and router-to-router architecture respectively under
both Windows and Linux platforms in comparison to those at IPv4. Though
theoretically IPv4 and IPv6 overhead difference benchmarking is 1.44%, but we find
here a little bit more due to its lack of maturity and still IPv6 is in its developing
stage. We also find some performance differences between the Linux and Windows
platforms for both in IPv4 and IPv6 implementations. This may be due to the
differences in the internal architectures of the two operating systems. Linux performs
better than Windows due to its kernel Buffer Allocation Strategies (BAS). The BAS
of Windows platform is perhaps weaker than its Linux counterpart.
iii
We also find that router-to-router tunneling performs always better than the host-tohost tunneling in all cases. Our inference is that host-to-host tunneling incurs more
overhead than the router-to-router tunneling; because routing devices work at layer 3
(network layer) level only, where memory, storage and processor are used by routers
(network layer), whereas for the host-to-host tunneling the operations take place over
all the layers.
iv
ACKNOWLEDGMENTS
Dr. M. Abdus Sobhan, my research advisor, is truly a one of a kind professor and
mentor. I do not even want to think where I might have been if I would not have met
him; I owe him everything for overseeing my research and advising me. Special
thanks go to the two most learned professors in my graduate career, Prof. Mohammed
Anwer and Prof. M. Abdus Sobhan for everything they have taught me about parallel
computing and computer networks respectively and the academic world in general. It
was their patience, expertise, and teaching ability that shaped me into what I am today
and made my thesis possible.
I like to extend my thanks to the faculty members, Dr. Indrani Haque, Dr. M.
Rokonuzzaman, Dr. Feroz Ahmed and Dr. Khosru M. Selim of SECS for their
support to my works.
Special thanks go to Mr. Nazmul Kabir, In-Charge of the SECS office for his wholehearted cooperation during my works.
I would like to thank to my friends, classmates and colleagues for their cooperation to
my thesis works.
I would like to thank Md. Badrudozza Swapan to inspire me to complete this course. I
especially want to thank my friend, Ioan Raicu, for his valuable suggestions. It is
obvious that without my parents, Late Mohammad Syed Ahmed and Monowara
Begum, my brother, Monir, my sister Momota and also my beloved wife Zishan Ara
who sacrificed her valuable time for me to prepare this thesis. None of my current
achievements would have been possible without her silent support. Family is truly the
most important part of my life.
TABLE OF CONTENTS
Page
LIST OF TABLES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
ix
LIST OF FIGURES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
CHAPTER
1
INTRODUCTION . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.1
INTRODUCTION . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2
AIMS AND OBJECTIVES OF THE STUDY . . . . . . . . . . . . ..
1.3
ORGANIZATION OF THE THESIS. . . . . .. . . .
LITERATURE REVIEW AND THEORETICAL DEVELOPMENT. . 4

2.1
LITERATURE REVIEW . . . . . . . . . . . . . . . . . . . . .
2.2
A LAYERING APPROACH.
2.2.1 Internet and the TCP/IP Reference Model.
IPv6 ACCOMPLISHMENT..
2.3.1 The IPv6 Specification
2.3.2 The IPv6 Addressing Architecture.
15
2.3.3 IPv4 vs. IPv6..
31
2.3
2.4
IPv4 TO IPv6 TRANSITION MECHANISMS AND

SCENARIO..
34
2.4.1 Dual IP Layer.
35
2.4.2 IPv6 Over IPv4 Tunneling.
35
METHODOLOGY . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
41
3.1
REVIEWING THE BASIC FUNCTIONALITIES AND

PERFORMANCE OF IPv4 AND IPv6.................
vi
41
CHAPTER
3.2
Page
STUDYING LAYERING APPROACHES AND ARCHITECTURES
OF IPv4 AND IPv6
41
3.3
LABORATORY SETUP FOR THE EXPERIMENT . . .
41
3.4
EXPERIMENTAL . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . ..
42
IPv4 AND IPv6 PERFORMANCE ANALYSIS . . . . . . . . . . . . .
44
4.1
PERFORMANCE METRICS.............. . . . . . . . . . . . . . . .
44
4.1.1 Bandwidth Utilization
45
4.1.2 Round Trip Time .... 45

4.2
POINT-TO-POINT TEST-LAB PERFORMANCE.. 46

46
4.2.2 Round Trip Time 51

4.3
ROUTER-TO-ROUTER TEST-LAB PERFORMANCE.. 53

54

4.4
5
CONCLUSION..
58
IPv4 TO IPv6 MIGRATION MECHANISMS AND

PERFORMANCE ANALYSIS..........
5.1
59
HOST-TO-HOST AND ROUTER-TO-ROUTER

TUNNELING PERFORMANCE .. 59
5.1.1 Bandwidth Utilization............
60

5.2
CONCLUSION.
vii
64
CHAPTER
6
Page
RESULTS AND DISCUSSIONS. . . . . . . . . . . .
65
6.1
INTRODUCTION.
65
6.2
RESULTS AND DISCUSSIONS..
65
6.2.1 Bandwidth Utilization for Point-to-Point

Architecture
65
6.2.2 Round Trip Time Computation

for Point-to-Point Architecture..
66

for Router-to-Router Architecture
67
6.2.4 Round Trip Time Computation

for Router-to-Router Architecture
68
6.2.5 Bandwidth Utilization for Host-to-Host

and Router-to-Router Tunneling Architecture..
69
6.2.6 Round Trip Time Computation for Host-to-Host

and Router-to-Router Tunneling Architecture 71
7
CONCLUSION AND SCOPE FOR FUTURE WORKS. . ..
72
7.1 CONCLUSION....
72
7.2 SCOPE FOR FUTURE WORKS . 73

REFERENCES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
APPENDIX
A
HARDWARE SPECIFICATIONS . . . . . . . . . . . . . . . . . . . . 76
SOFTWARE SPECIFICATIONS . . . . . . . . . . . 76
THEORETICAL IP PACKET OVERHEAD.. 77
TESTING TOOLS SPECIFICATIONS.
78
IPv6 CONFIGURATIONS IN DIFFERENT PLATFORMS
79
LOGS GENERATED BY TESTING TOOLS 82

viii
LIST OF TABLES
Table
Page
2.1 Values of the Next Header Field of IPv6..
15
2.2 Differences between IPv4 and IPv6... 31

2.3 IPv4 Addresses and IPv6 Equivalents....... 32
2.4 Comparing the IPv4 and IPv6 Headers.
ix
33
LIST OF FIGURES
Figure
Page
2.1 Internet Model...
2.2 The IPv4 Header...
10
2.3 The IPv6 Header 13

2.4 The global Unicast Address as defined in RFC 3587 19
2.5 The three-level structure of the global unicast address.
20
2.6 The link-local address 21

2.7 The site-local address
22
2.8 The local address 22

2.9 The IPv6 multicast address 24
2.10 The 48-bit IEEE 802 address 27
2.11 The EUI-64 address..
28
2.12 The conversion of an IEEE 802 address to an EUI-64 address
28
2.13 The conversion of a universally administered, unicast

EUI-64 address to an IPv6 interface identifier.
29
2.14 The conversion of a universally administered, unicast

IEEE 802 address to an IPv6 interface identifier..
29
2.15 A Dual IP Layer Architecture...
35
2.16 IPv6 over IPv4 Tunneling....
36
2.17 Router-to-Router Tunneling..
37
2.18 Host-to-Router and Router-to-Host Tunneling.
38
2.19 Host-to-Host Tunneling....
39
4.1 Point-to-Point Test-Labs Architecture; two computers are directly

connected through Unshielded Twisted Pair cross Ethernet cable 46
4.2 Bandwidth Utilization Results for IPv4/IPv6 under Windows
with data size ranging from 128 KB to 1.408 MB. 46
with data size ranging from 5.12 to 61.44 MB....
47
4.4 Bandwidth Utilization Results for IPv4/IPv6 under Linux

with data size ranging from 128 KB to 1.408 MB....
47

with data size ranging from 5.12 to 61.44 MB..................
48
4.6 Bandwidth Utilization Results for IPv4 under Linux and

Windows with data size ranging from 128 KB to 1.408 MB.... 48
Windows with data size ranging from 128 KB to 1.408 MB...
49
4.8 Bandwidth Utilization Results for IPv4 under Linux

and Windows with data size ranging from 5.12 to 61.44 MB......
49

Windows with data size ranging from 5.12 to 61.44 MB.
50
4.10 Bandwidth Utilization Results for IPv4/IPv6 under Linux and

Windows with data size ranging from 5.12 to 61.44 MB.
50

with data size ranging from 128 KB to 1.408 MB 51
4.12 Round Trip Time Results for IPv4/IPv6 under Windows with data
size ranging from 5.12 to 61.44 MB.
xi
51
4.13 Round Trip Time Results for IPv4/IPv6 under Linux with data
size ranging from 5.12 to 61.44 MB.
52
4.14 Round Trip Time Results for IPv4/IPv6 under Linux and Windows
with data size ranging from 5.12 to 61.44 MB.
52
4.15 Router-to-Router Test-Labs Architecture; two computers are directly

connected through Unshielded Twisted Pair cross Ethernet cable to
each router and two router also directly connected through
Unshielded Twisted Pair cross Ethernet cable as WAN connection
53

with data size ranging from 128 KB to 1.408 MB.
54

with data size ranging from 5.12 to 61.44 MB.
54

with data size ranging from 128KB to 1.408 MB.. 55
with data size ranging from 5.12 to 61.44 MB... 55
4.20 Bandwidth Utilization Results for IPv4/IPv6 under Linux and
Windows with data size ranging from 5.12 to 61.44 MB.............
56

with data size ranging from 128KB to 1.408 MB.
56
4.22 Round Trip Time Results for IPv4/IPv6 under Windows

with data Size ranging from 5.12 to 61.44 MB.....
57
4.23 Round Trip Time Results for IPv4/IPv6 under Linux

with data Size ranging from 5.12 to 61.44 MB.. 57
xii
4.24 Round Trip Time Results for IPv4/IPv6 under Linux and Windows
with data size ranging from 5.12 to 61.44 MB.. 58
5.1 Host-to-Host Tunneling Architecture.... 59
5.2 Router-to-Router Tunneling Architecture.
60
5.3 Bandwidth Utilization Results for IPv4(IPv6) Host-to-Host and

Router-to-Router Tunneling under Windows and Cisco with data
size ranging from 5.12 to 61. 44 MB
60
5.4 Bandwidth Utilization Results for IPv4(IPv6) Host-to-Host, Routerto-Router Tunneling and IPv6 Router-to-Router infrastructure under
Windows and Cisco with data size ranging from 5.12 to 61.44 MB....
61
5.5 Bandwidth Utilization Results for IPv4(IPv6) Host-to-Host and

Router-to-Router Tunneling under Linux and Cisco with data
size ranging from 5.12 to 61.44 MB.. 61
5.6 Bandwidth Utilization Results for IPv4(IPv6) Host-to-Host, Routerto-Router Tunneling and IPv6 Router-to-Router infrastructure under
Linux and Cisco with data size ranging from 5.12 to 61.44 MB... 62
5.7 Bandwidth Utilization Results for IPv4(IPv6) Host-to-Host, Router-toRouter Tunneling and IPv6 Router-to-Router infrastructure under Linux
,Windows and Cisco with data size ranging from 5.12 to 61.44 MB.
62
5.8 Round Trip Time Results for IPv4 (IPv6) Tunneling under Windows
and Cisco with data size ranging from 5.12 to 61.44 MB. 63
5.9 Round Trip Time Results for IPv4 (IPv6) Tunneling under Linux and
Cisco with data size ranging from 5.12 to 61.44 MB..... .. 63
5.10 Round Trip Time Results for IPv4 (IPv6) Tunneling under Linux,
Windows, Cisco platforms with data size ranging from 5.12 to 61.44 MB...64
xiii
PREFACE
In this thesis, we attempt to introduce the reader with some fundamental process of
transition mechanism of the Internet Protocol (IP) version 4 to 6. This paper presents
detailed knowledge of protocols what is actually needed to know whoever wants to be
in Internet related profession like system administrator, network administrator,
network engineer and network manager, especially to look for the design and
implementation of IPv6 enabled application and network.
The Author
xiv
CHAPTER 1
INTRODUCTION
1.1
INTRODUCTION
In 1970, Internet Protocol was designed and introduced to industry in 1981 to

objective of the interconnecting of heterogeneous network technologies.
IP plays a
key role to get popularity of Internet. The huge success of the Internet is pushing IPv4
to its limits [1]. Internet Engineering Task Force (IETF) [2] took initiative to address
the limitations of IPv4 in 1990s. IPv4 uses a 32-bit field to identify host interfaces
known as Internet Protocol Addresses. When IPv4 was designed 32 bits were enough
and the IETF never thought of any limitations of IPv4 for support such a big network
like Internet. This 32-bit field is becoming restrictive nowadays; an Internet Address
is in short supply. The IETF began to design a successor to IPv4: IPv6 ((Internet
Protocol version 6). IPv6 [3] is the new version of the Internet Protocol and it has
several improvements. It has extended addressing capabilities; the address field is
128-bits in length. With IPv6, we a have a far greater address space (3.4238
addresses), we can connect more devices to the Internet without breaking the end-toend principle, create a complex address hierarchy and benefit from simpler
configuration. IPv6 also provides an improved header format and routers are able to
process the IPv6 header in a more efficient way. Options (e.g. mobility and security)
are a patch in the IPv4 header but, in IPv6, such features are part of the protocol
(using the new extension header format).
In summary, the Internet will be even more scalable with IPv6 than with IPv4. The
Internet is still using IPv4, but IPv6 is now being widely deployed in research
networks, and this deployment is a critical issue. In the future it is possible that the
Internet will be IPv6 only but, until that moment, IPv4 and IPv6 must coexist. IPv6
deployment must not disrupt the current Internet and, somehow, IPv4 and IPv6 must
coexist. This is accomplished by special mechanisms, named transition mechanisms,
which allow communication between the IPv4 and the IPv6 world. Transition
mechanisms have been designed and implemented but they provide less forwarding
speed than a native communication (IPv4 to IPv4 or IPv6 to IPv6) and some of them
are difficult to deploy.
The proposed study intend to examine the performance of both the IPv4 and IPv6
protocols in two different platforms, namely Microsoft Windows 2003 Server and
Red Hat Linux Enterprise Version 4 on identical hardware and IPv6 transition
mechanism. Our experiments were conducted over an unloaded network using two
routers and two workstations.
1.2
AIMS AND OBJECTIVES OF THE STUDY
The broad objective of the study is to compare the two protocol stacks (IPv4 and
IPv6) and transition mechanism to IPv6. Specific objectives are:
i.
to evaluate the performance characteristics of IPv4 and IPv6 protocols in

two different platforms (Windows and Linux ) on identical hardware;
ii.
to evaluate the performance characteristics of IPv6 transition; and
iii.
to present the different types of transition from IPv4 to IPv6 protocol

stacks.
1.3
ORGANIZATION OF THE THESIS
Chapter 2 covers some theoretical developments and literature review about IPv4 and
IPv6 in general, and some of the fundamental differences between the two network
protocols stack; it also describes various transition mechanisms that are available
when upgrading from IPv4 to IPv6. Chapter 3 explains the methodology to achieve
the objectives of the study. In chapter 4, explains testing results of IPv4 versus IPv6
under two different platforms with various matrices. Chapter 5 focuses on the
transition mechanisms evaluation. Chapter 6 covers results and discussions of the
performance. Chapter 7 furnishes conclusion and suggestion for further works.
Finally, Appendices A, B, C, D, E, F which includes Hardware, Software, Theoretical
IP packet overhead, Testing Tools specifications, IPv6 configuration (for Cisco,
Windows and Linux platforms), and some testing result logs respectively.
CHAPTER 2
LITERATURE REVIEW AND THEORETICAL DEVELOPMENT
The main objectives of this chapter are to introduce the theoretical concept of IPv4
and IPv6 and its transition mechanism. We discussed some papers on the issue. In
near future, we are going to use IPv6 with IPv4 protocol, but we need to see the
architectural differences and relation among them. For this reason, we are motivated
to find out the gap or advantages and disadvantages of the two protocols.
2.1
LITERATURE REVIEW
Though, there exist several analyses on IPv4 and IPv6 protocol stacks under different
implementation environments like Windows NT, Windows 2000. IPv6 protocol stack
was not that much mature that time, but in recent version under Microsoft Windows
2003 Server, Red Hat Linux Enterprise Version 4 are quite mature and can be used in
the industry. It is difficult to test IPv6 functionalities under Cisco router in real time
Internet use. Some experiments used software router and PC (Personal Computer)
environment which actually do not give the real results. It is often impossible to
arrange such latest equipment in a laboratory because of its high cost.
Moreover, we tested two different platforms, namely Microsoft Windows 2003 Server
and Red Hat Linux Enterprise version 4, side by side, throughout all of our
experiments; we covered both TCP and UDP transport protocols. Our metrics
included bandwidth utilization (throughput), round trip time (latency) parameters. The
following paragraphs cover some of the related work that we are going to do.
Writers (Marc E. Fiuczynski, Vincent K. Lam and Brian N. Bershad) [4] develop a
translator program under Windows NT which maps IPv4 to IPv6. To evaluate the
performance of the translator they used the ttcp tool to measure bandwidth and ping to
measure latency between a pair of IPv6 and IPv4 hosts. They compare the packet
forwarding performance of the IPv6/IPv4 translator with NTs built-in IPv4
forwarding support. They actually evaluate the performance of own develop
translator, not IPv6 implementation in Windows NT.
Ioan Raicu [5] only concentrated on obtaining RTT for as many scenarios as he could,
gathering data from packet transfers from 64 B to 64 KB under TCP, UDP, IPv4,
IPv6, Windows NT 4.0, Windows 2000. He experimented with socket buffers of
various sizes, but came to the conclusion that in todays world of high speed networks
in the Gbits/s bandwidth, larger buffers would be preferred over smaller ones. He
used 60 KB buffers for all the displayed results. It is a similar experiment we are
going to do. But he did not do throughput test what we did in our experiment.
Writers (Yi Wang, Shaozhi Ye and Xing Li) [6] present a measurement study of
current IPv6 performance conducted CERNET (China Education and Research
Network). They study 685,680 packet-level traces with 133,340 million packets
collected from 936 IPv6/IPv4 dual stack Web servers located in 44 countries. Their
measurement results show that IPv6 connections tend to have smaller round trip times
than their IPv4 counterparts, but suffer higher packet loss rate at the same time. They
also notice that tunneled paths do not show a notable degraded performance compared
with native paths. They actually test IPv6 in a loaded network and in different sties
IPv6 enabled web server using wget and tcpdump in FreeBSD platform. This test
may not show real performance difference of IPv6 due to loaded network and some
times some network may not work properly due to various reasons. However, they
optimistic about the IPv6 performance in comparison with IPv4 results. They tested
application performance under IPv6 and Pv4 environments.
IPv6 testing [7] can be divided into four basic categories: conformance, functional,
performance, and application [8]. The author performed only application test on
different applications named web, ftp, email etc. In this test-lab they measured only
application response time. They test under Linux platform only, so we did not get real
scenario for comparison with other platforms.
Authors (Yi Wang, Shaozhi Ye, Xing Li) [9] evaluated the MSR IPv6 BETA protocol
stack for Windows NT 4.0. The author evaluated the performance of MSR IPv6
protocol stack by measuring and analyzing its network latency, throughput, and
processing overheads. Their test-lab consisted of two Pentium machines with
100Mbps fast Ethernet connected via an unloaded switch. The work presented seems
interesting and contains only a small part of our work. First of all, it only evaluated
IPv6 and did not compare it with IPv4. Secondly, they only evaluated the Windows
NT implementation and did not compare it with any other implementations. It is to
notice that there were no routers involved in their experimentation and only connected
the hosts with a switch. Obviously the findings they made are nearly obsolete since
IPv6 and computing hardware evolved so much since 1999. For example the MSR
IPv6 protocol stack has been replaced by the Windows 2000 IPv6 Preview Protocol
Stack. Regardless, their work showed very interesting initial results on IPv6.
Ioan Raicu [10] evaluated the performance of data transmission over IPv4 and IPv6
using various security protocols. The authors choose a particular application, namely
digital video (DV) transmission in order to execute their experiments. They utilized
end hosts with FreeBSD 2.2.8 and KAME IPv6 protocol stack and a router
implemented in a PC platform also running FreeBSD 2.2.8 and KAME IPv6 protocol
stack. The criticism of this work lies in the fact that the routers utilized obviously did
not support most of the router functions in the hardware and therefore the depicted
performance is lower than the performance in a real world scenario in which actual
hardware routers could be utilized. One of the other criticisms is that they only
covered small sample of the test we performed. They utilized two different buffer
sizes (57344 bytes and 32769 bytes), which makes no sense; it is a known fact that
when performing experiments of this nature, the buffer size is kept constant
throughout all the experiments. They claim that the MTU size they used was either
1024 or 4096 bytes; however IP routers do not support MTU sizes above 1514 bytes.
They might have had the functionality to change the MTU size beyond the maximum
due to the software router implementation they were using. Obviously such a large
MTU size might yield falsely higher than usual results. The only place where they
mentioned the data size, they specified 32 KB data, but they called it the socket size.
As an overall evaluation, the depicted results are interesting, but not complete in the
sense of depicting real world performance.
After reading all the literature related to our work performed by a section of the
research community, we are motivated to start a performance analysis with newly
introduced IPv6 protocol in different platforms and transition mechanism with
identical hardware.
2.2
A LAYERING APPROACH
Layering approach [10] is one of the major reasons network architectures have been
so successful. One great success story is the Internet, which shows how robust and
scalable it has been despite the initial design goals which did not foresee the
exponential growth that it inured.
Layering helps break complex problems into smaller and more manageable pieces. It
helps reduce design complexity and simplifies the design and testing protocols Sender
and receiver software can be tested, designed and implemented independently.
Layering prevents changes in software from propagation to other layers. It allows
designers to construct protocol suites and allows ease of change regarding an
implementation of a service. Some of its drawbacks include some performance loss,
time delay, and perhaps having more than 1 copy of data at any given moment.
Obviously, these drawbacks are quickly overshadowed by all the advantages of a
layered approach to designing protocols.
The basic definition of layering is that the layer N software on the receiving machine
should receive the exact message sent by the layer N software at the sender machine.
It should satisfy whatever transformation was applied to the packet should be

completely reversible at the receiving side.
2.2.1 Internet and the TCP/IP Reference Model

The Internet model is made of five layers. The four lower layers roughly match the
four lower layers of the OSI model. Most of the responsibilities of the three topmost
layers of the OSI model are assigned to the Internet models application layer, with
some of the session layer duties going to the transport layer. Figure 2.1 shows the
Internet model compared to the OSI model [11].
Application Layer Email, File Transfer, Browsing, Chatting,
Transport Layer
TCP
UDP
TCP
UDP
Internet Layer
IPv4
IPv6
Data and Physical Link Layer
Ethernet
Figure 2.1 Internet Model
2.3
IPv6 ACCOMPLISHMENT
IPv6 provides capabilities that go beyond larger address. These include a streamlined
packet format, support for source routing, as well as integrated authentication and
encryption for enhance security. Also of importance is a key difference between the
IPv4 and IPv6 architectures; IPv4 is 32-bits aligned, whereas IPv6 is 64-bits aligned.
As a result, when 64-bit processors are used, IPv6 packets can be processed much
faster than IPv4 packets.
2.3.1 The IPv6 Specification

Before we describe the capabilities of IPv6, we furnish a brief review of the existing
standard, IPv4.
The Benchmark: IPv4

The Internet Protocol (IP) [1] was developed to provide the functions necessary to
deliver a package of bits from a source to destination over an interconnected system
of networks. IP primarily concerned with delivery of the datagram. The term
datagram refers to a package of data transmitted over a connectionless using UDP and
connection-oriented using TCP protocol. In process of delivering datagram, IP must
deal with addressing and fragmentation. Fragmentation is necessary due to different
types of LAN and WAN use different size framing.
Figure 19 shows the IPv4 header described in RFC 791.
Figure 2.2 The IPv4 Header

The fields in the IPv4 header are:
Version Indicates the version of IP and is set to 4. The size of this field is 4 bits.
Internet Header Length Indicates the number of 4-byte blocks in the IPv4 header.
The size of this field is 4 bits. Because an IPv4 header is a minimum of 20 bytes in
size, the smallest value of the Internet Header Length (IHL) field is 5. IPv4 options
can extend the minimum IPv4 header size in increments of 4 bytes. If an IPv4 option
does not use all 4 bytes of the IPv4 option field, the remaining bytes are padded with
10
0s, making the entire IPv4 header an integral number of 32-bits (4 bytes). With a
maximum value of 0xF, the maximum size of the IPv4 header including options is 60
bytes (154).
Type of Service Indicates the desired service expected by this packet for delivery
through routers across the IPv4 internetwork. The size of this field is 8 bits, which
contain bits for precedence, delay, throughput, and reliability characteristics.
Total Length Indicates the total length of the IPv4 packet (IPv4 header + IPv4
payload) and does not include link layer framing. The size of this field is 16 bits,
which can indicate an IPv4 packet that is up to 65,535 bytes long.
Identification Identifies this specific IPv4 packet. The size of this field is 16 bits.
The Identification field is selected by the originating source of the IPv4 packet. If the
IPv4 packet is fragmented, all of the fragments retain the Identification field value so
that the destination node can group the fragments for reassembly.
Flags Identifies flags for the fragmentation process. The size of this field is 3 bits;
however, only 2 bits are defined for current use. There are two flagsone to indicate
whether the IPv4 packet might be fragmented and another to indicate whether more
fragments follow the current fragment.
Fragment Offset Indicates the position of the fragment relative to the original IPv4
payload. The size of this field is 13 bits.
Time to Live Indicate the maximum number of links on which an IPv4 packet can
travel before being discarded. The size of this field is 8 bits. The Time-to-Live field
(TTL) was originally used as a time count with which an IPv4 router determined the
length of time required (in seconds) to forward the IPv4 packet, decrementing the
TTL accordingly. Modern routers almost always forward an IPv4 packet in less than a
11
second and are required by RFC 791 to decrement the TTL by at least one. Therefore,
the TTL becomes a maximum link count with the value set by the sending node.
When the TTL equals 0, an ICMP Time Expired-TTL Expired in Transit message is
sent to the source IPv4 address and the packet is discarded.
Protocol Identifies the upper layer protocol. The size of this field is 8 bits. For
example, TCP uses a Protocol of 6, UDP uses a Protocol of 17, and ICMP uses a
Protocol of 1. The Protocol field is used to demultiplex an IPv4 packet to the upper
layer protocol.
Header Checksum Provides a checksum on the IPv4 header only. The size of this
field is 16 bits. The IPv4 payload is not included in the checksum calculation as the
IPv4 payload and usually contains its own checksum. Each IPv4 node that receives
IPv4 packets verifies the IPv4 header checksum and silently discards the IPv4 packet
if checksum verification fails. When a router forwards an IPv4 packet, it must
decrement the TTL. Therefore, the Header Checksum is recomputed at each hop
between source and destination.
Source Address Stores the IPv4 address of the originating host. The size of this field
is 32 bits.
Destination Address Stores the IPv4 address of the destination host. The size of this
field is 32 bits.
Options Stores one or more IPv4 options. The size of this field is a multiple of 32
bits. If the IPv4 option or options do not use all 32 bits, padding options must be
added so that the IPv4 header is an integral number of 4-byte blocks that can be
indicated by the Internet Header Length field.
12
The IPv6 specification is defined in RFC 2460 [3]. RFC 2460 summarizes the
following changes from IPv4 to IPv6:
Figure 2.3 shows the IPv6 header as defined in RFC 2460.
Figure 2.3 The IPv6 Header

The fields in the IPv6 header are:
Version 4 bits are used to indicate the version of IP and is set to 6.
Traffic Class Indicates the class or priority of the IPv6 packet. The size of this field
is 8 bits. The Traffic Class field provides similar functionality to the IPv4 Type of
Service field. The use of the Traffic Class field is defined in RFC 3697.
Flow Label Indicates that this packet belongs to a specific sequence of packets
between a source and destination, requiring special handling by intermediate IPv6
routers. The size of this field is 20 bits. The Flow Label is used for non-default quality
of service connections, such as those needed by real-time data (voice and video). For
default router handling, the Flow Label is set to 0. There can be multiple flows
between a source and destination, as distinguished by separate non-zero Flow Labels.
Payload Length Indicates the length of the IPv6 payload. The size of this field is 16
13
bits. The Payload Length field includes the extension headers and the upper layer
PDU. With 16 bits, an IPv6 payload of up to 65,535 bytes can be indicated. For
payload lengths greater than 65,535 bytes, the Payload Length field is set to 0 and the
Jumbo Payload option is used in the Hop-by-Hop Options extension header.
Next Header Indicates either the first extension header (if present) or the protocol in
the upper layer PDU (such as TCP, UDP, or ICMPv6). The size of this field is 8 bits.
When indicating an upper layer protocol above the Internet layer, the same values
used in the IPv4 Protocol field are used here.
Hop Limit Indicates the maximum number of links over which the IPv6 packet can
travel before being discarded. The size of this field is 8 bits. The Hop Limit is similar
to the IPv4 TTL field except that there is no historical relation to the amount of time
(in seconds) that the packet is queued at the router. When the Hop Limit equals 0, an
ICMPv6 Time Exceeded message is sent to the source address and the packet is
discarded.
Source Address Stores the IPv6 address of the originating host. The size of this field
is 128 bits.
Destination Address Stores the IPv6 address of the current destination host. The size
of this field is 128 bits. In most cases the Destination Address is set to the final
destination address. However, if a Routing extension header is present, the
Destination Address might be set to the next router interface in the source route list.
Values of the Next Header Field
14
Table 2.1 shows the typical values of the Next Header field for an IPv6 header or an
IPv6 extension header.
Table 2.1 Values of the Next Header Field of IPv6
Value (in decimal) Header
0
Hop-by-Hop Options Header
TCP
17
UDP
41
Encapsulated IPv6 Header
43
Routing Header
44
Fragment Header
46
Resource ReSerVation Protocol
50
Encapsulating Security Payload
51
Authentication Header
58
ICMPv6
59
No next header
60
Destination Options Header
2.3.2 The IPv6 Addressing Architecture

The Addressing Benchmark: IPv4
The IPv4 definition, RFC 791 [1], also specified that protocols address structure.
Each of the 32-bit IP address are divided into Host ID and Network ID sections, and
may take one of five formats. The formats differ in the number of bits that are
allocated to the Host and Network IDs and are identified by the first three bits. Class
A addresses are identified by Bit 0. Bits 1 through 7 identify the network, and bits 8
through 31 identify the specific host on the network. With a seven bit Network ID,
only 128 class A addresses are available. Of these, address 0 and 127 are reserved.
Class B addresses are identified by the first two bits having a value of 10 (binary).
The next 14 bits identify the Network and the remaining 16 bits identify the Host.
16384 Class B addresses are possible, with addresses 0 and 16,383 reserved. Class C
addresses begin with a binary 110. The next 21 bits identify the Network, and the
15
remaining 8 bits identify the Host. A total of 2,097,152 Class C addresses are
possible, with addresses 0 and 2,097,151 reserved. Class D addresses begin with a
binary 1110 and are intended for multicasting purpose. Class E addresses begin with a
binary 1111 and are reserved for future use. It also supports subnetting and Classless
Interdoamin Routing.
The IPv6 Address Space
The most obvious distinguishing feature of IPv6 is its use of much larger addresses.
The size of an address in IPv6 is 128 bits, which is four times the larger than an IPv4
address. A 32-bit address space allows for 232 or 4,294,967,296 possible addresses.
A 128-bit address space allows for 2128 or 340,282,366,920,938,463,463,374,
607,431,768,211,456 (or 3.41038) possible addresses.
In the late 1970s when the IPv4 address space was designed, it was unimaginable that
it could be exhausted. However, due to changes in technology and an allocation
practice that did not anticipate the recent explosion of hosts on the Internet, the IPv4
address space was consumed to the point that by 1992 it was clear that a replacement
would be necessary.
With IPv6, it is even harder to conceive that the IPv6 address space will be consumed.
To help put this number in perspective, a 128-bit address space provides
655,570,793,348,866,943,898,599 (6.51023) addresses for every square meter of the
Earths surface.
It is important to remember that the decision to make the IPv6 address 128 bits in
length was not so that every square meter of the Earth could have 6.51023 addresses.
Rather, the relatively large size of the IPv6 address is designed to be subdivided into
hierarchical routing domains that reflect the topology of the modern-day Internet. The
16
use of 128 bits allows for multiple levels of hierarchy and flexibility in designing
hierarchical addressing and routing that is currently lacking on the IPv4-based
Internet.
The IPv6 addressing architecture is described in RFC 3513.
IPv6 Address Syntax
IPv4 addresses are represented in dotted-decimal format. This 32-bit address is
divided along 8-bit boundaries. Each set of 8 bits is converted to its decimal
equivalent and separated by periods. For IPv6, the 128-bit address is divided along
16-bit boundaries, and each 16-bit block is converted to a 4-digit hexadecimal number
and separated by colons. The resulting representation is called colon-hexadecimal.
The following is an IPv6 address in binary form:
0010000111011010000000001101001100000000000000000010111100111011
0000001010101010000000001111111111111110001010001001110001011010
The 128-bit address is divided along 16-bit boundaries:
0010000111011010 0000000011010011 0000000000000000 0010111100111011
0000001010101010 0000000011111111 1111111000101000 1001110001011010
Each 16-bit block is converted to hexadecimal and delimited with colons. The result
is:
21DA:00D3:0000:2F3B:02AA:00FF:FE28:9C5A
IPv6 representation can be further simplified by removing the leading zeros within
each 16-bit block. However, each block must have at least a single digit. With leading
zero suppression, the address representation becomes:
21DA:D3:0:2F3B:2AA:FF:FE28:9C5A
17
IPv6 Prefixes
The prefix is the part of the address that indicates the bits that have fixed values or are
the bits of the subnet prefix. Prefixes for IPv6 subnets, routes, and address ranges are
expressed in the same way as Classless Inter-Domain Routing (CIDR) notation for
IPv4. An IPv6 prefix is written in address/prefix-length notation. For example,
21DA:D3::/48 is a route prefix and 21DA:D3:0:2F3B::/64 is a subnet prefix.
Types of IPv6 Addresses
There are three types of IPv6 addresses:
Unicast
A unicast address identifies a single interface within the scope of the type of unicast
address. With the appropriate unicast routing topology, packets addressed to a unicast
address are delivered to a single interface.
Multicast
A multicast address identifies multiple interfaces. With the appropriate multicast
routing topology, packets addressed to a multicast address are delivered to all
interfaces that are identified by the address. A multicast address is used for one-tomany communication, with delivery to multiple interfaces.
Anycast
An anycast address identifies multiple interfaces. With the appropriate routing
topology, packets addressed to an anycast address are delivered to a single interface,
the nearest interface that is identified by the address. The nearest interface is
defined as being closest in terms of routing distance. An anycast address is used for
one-to-one-of-many communication, with delivery to a single interface.
18
In all cases, IPv6 addresses identify interfaces, not nodes. A node is identified by any
unicast address assigned to one of its interfaces.
Links and Subnets
Similar to IPv4, an IPv6 subnet prefix is assigned to a single link. Multiple subnet
prefixes can be assigned to the same link. This technique is called multinetting.
Unicast IPv6 Addresses
The following types of addresses are unicast IPv6 addresses:
Global unicast addresses
Link-local addresses
Site-local addresses
Unique local IPv6 unicast addresses
Special addresses
Global Unicast Addresses
Global unicast addresses are equivalent to public IPv4 addresses. They are globally
routable and reachable on the IPv6 portion of the Internet.
Figure 2.4 shows the structure of global unicast addresses currently being allocated by
IANA, as defined in RFC 3587.
Figure 2.4 The global unicast address as defined in RFC 3587
19
The fields in the global unicast address are the following:

Fixed portion set to 001 The three high-order bits are set to 001. The address prefix
for currently assigned global addresses is 2000::/3.
Global Routing Prefix Indicates the global routing prefix for a specific
organization's site. The combination of the three fixed bits and the 45-bit Global
Routing Prefix is used to create a 48-bit site prefix, which is assigned to an individual
site of an organization. Once assigned, routers on the IPv6 Internet forward IPv6
traffic matching the 48-bit prefix to the routers of the organization's site.
Subnet ID The Subnet ID is used within an organization's site to identify subnets.
The size of this field is 16 bits. The organization's site can use these 16 bits within its
site to create 65,536 subnets or multiple levels of addressing hierarchy and an efficient
routing infrastructure.
Interface ID Indicates the interface on a specific subnet within the site. The size of
this field is 64 bits.
The fields within the global unicast address create a three-level structure shown in
Figure 2.5.
Figure 2.5
The three-level structure of the global unicast address
The public topology is the collection of larger and smaller ISPs that provide access to
the IPv6 Internet. The site topology is the collection of subnets within an
organizations site. The interface identifier identifies a specific interface on a subnet
within an organizations site. For more information about global unicast addresses,
see RFC 3587.
20
Local-Use Unicast Addresses

There are two types of local-use unicast addresses:
Link-local addresses are used between on-link neighbors and for Neighbor Discovery
processes.
Site-local addresses are used between nodes communicating with other nodes in the
same site.
Link-Local Addresses
Link-local addresses are used by nodes when communicating with neighboring nodes
on the same link.
Figure 2.6 shows the structure of the link-local address.
Figure 2.6 The link-local address

Link-local addresses always begin with FE80. With the 64-bit interface identifier, the
prefix for link-local addresses is always FE80::/64. An IPv6 router never forwards
link-local traffic beyond the link.
Site-Local Addresses
Site-local addresses are equivalent to the IPv4 private address space (10.0.0.0/8,
172.16.0.0/12, and 192.168.0.0/16). Unlike link-local addresses, site-local addresses
are not automatically configured and must be assigned either through stateless or
stateful address configuration processes.
21
Figure 2.7 shows the structure of the site-local address.
Figure 2.7 The site-local address

The first 10-bits are always fixed for site-local addresses (FEC0::/10). After the 10
fixed bits is a Subnet ID field that provides 54 bits with which you can create a
hierarchical and summarizable routing infrastructure within the site. After the Subnet
ID field is a 64-bit Interface ID field that identifies a specific interface on a subnet.
Unique Local IPv6 Unicast Addresses
To replace site-local addresses with a new type of address that is private to an
organization, yet unique across all of the sites of the organization, RFC 4193 defines
Unique Local IPv6 Unicast Addresses, also known as local addresses. Figure 2.8
shows the structure of local addresses.
Figure 2.8 The local address
Special IPv6 Addresses

The following are special IPv6 addresses:
Unspecified address
The unspecified address (0:0:0:0:0:0:0:0 or ::) is only used to indicate the absence of
an address. It is equivalent to the IPv4 unspecified address of 0.0.0.0.
22
Loopback address
The loopback address (0:0:0:0:0:0:0:1 or ::1) is used to identify a loopback interface,
enabling a node to send packets to itself. It is equivalent to the IPv4 loopback address
of 127.0.0.1.
Compatibility Addresses
To aid in the migration from IPv4 to IPv6 and the coexistence of both types of hosts,
the following addresses are defined:
IPv4-compatible address
The IPv4-compatible address, 0:0:0:0:0:0:w.x.y.z or ::w.x.y.z (where w.x.y.z is the
dotted decimal representation of an IPv4 address), is used by IPv6/IPv4 nodes that are
communicating using IPv6.
IPv4-mapped address
The IPv4-mapped address, 0:0:0:0:0:FFFF:w.x.y.z or ::FFFF:w.x.y.z, is used to
represent an IPv4-only node to an IPv6 node.
6to4 address
The 6to4 address is used for communicating between two nodes running both IPv4
and IPv6 over an IPv4 routing infrastructure.
Multicast IPv6 Addresses
In IPv6, multicast traffic operates in the same way that it does in IPv4. Arbitrarily
located IPv6 nodes can listen for multicast traffic on an arbitrary IPv6 multicast
address. IPv6 nodes can listen to multiple multicast addresses at the same time. Nodes
can join or leave a multicast group at any time.
23
Figure 2.9 shows the IPv6 multicast address.
Figure 2.9 The IPv6 multicast address

The fields in the multicast address are:
Flags Indicates flags set on the multicast address. The size of this field is 4 bits. As
of RFC 3513, the only flag defined is the Transient (T) flag. The T flag uses the loworder bit of the Flags field. When set to 0, the T flag indicates that the multicast
address is a permanently assigned (well-known) multicast address allocated by the
Internet Assigned Numbers Authority (IANA). When set to 1, the T flag indicates that
the multicast address is a transient (non-permanently-assigned) multicast address.
Scope Indicates the scope of the IPv6 internetwork for which the multicast traffic is
intended. The size of this field is 4 bits. In addition to information provided by
multicast routing protocols, routers use the multicast scope to determine whether
multicast traffic can be forwarded. The most prevalent values for the Scope field are 1
(interface-local scope), 2 (link-local scope), and 5 (site-local scope).
For example, traffic with the multicast address of FF02::2 has a link-local scope. An
IPv6 router never forwards this traffic beyond the local link.
Group ID Identifies the multicast group and is unique within the scope. The size of
this field is 112 bits. Permanently assigned group IDs are independent of the scope.
Transient group IDs are only relevant to a specific scope. Multicast addresses from
FF01:: through FF0F:: are reserved, well-known addresses.
24
Anycast IPv6 Addresses

An anycast address is assigned to multiple interfaces. Packets addressed to an anycast
address are forwarded by the routing infrastructure to the nearest interface to which
the anycast address is assigned. In order to facilitate delivery, the routing
infrastructure must be aware of the interfaces assigned anycast addresses and their
distance in terms of routing metrics.
IPv6 Addresses for a Host
An IPv4 host with a single network adapter typically has a single IPv4 address
assigned to that adapter. An IPv6 host, however, usually has multiple IPv6
addresseseven with a single interface. An IPv6 host is assigned the following
unicast addresses:
A link-local address for each interface
Unicast addresses for each interface (which could be a site-local address and one or
multiple global unicast addresses)
The loopback address (::1) for the loopback interface
Typical IPv6 hosts are logically multihomed because they have at least two addresses
with which they can receive packetsa link-local address for local link traffic and a
routable site-local or global address.
Additionally, each host is listening for traffic on the following multicast addresses:
The interface-local scope all-nodes multicast address (FF01::1)
The link-local scope all-nodes multicast address (FF02::1)
The solicited-node address for each unicast address on each interface
The multicast addresses of joined groups on each interface
25
IPv6 Addresses for a Router

An IPv6 router is assigned the following unicast addresses:
A link-local address for each interface
Unicast addresses for each interface (which could be a site-local address and one or
multiple global unicast addresses)
A Subnet-Router anycast address
Additional anycast addresses (optional)
The loopback address (::1) for the loopback interface
Additionally, each router is listening for traffic on the following multicast addresses:
The interface-local scope all-nodes multicast address (FF01::1)
The interface-local scope all-routers multicast address (FF01::2)
The link-local scope all-nodes multicast address (FF02::1)
The link-local scope all-routers multicast address (FF02::2)
The site-local scope all-routers multicast address (FF05::2)
The solicited-node address for each unicast address on each interface
The multicast addresses of joined groups on each interface
IPv6 Interface Identifiers
The last 64 bits of an IPv6 address are the interface identifier that is unique to the 64bit prefix of the IPv6 address. The ways in which an IPv6 interface identifier are
determined are as follows:
A 64-bit interface identifier that is derived from the Extended Unique Identifier
(EUI)-64 address.
A randomly generated interface identifier that changes over time to provide a level of
anonymity.
26
An interface identifier that is assigned during stateful address autoconfiguration (for

example, through DHCPv6). DHCPv6 standards are currently being defined.
EUI-64 address-based interface identifiers
RFC 3513 states that all unicast addresses that use the prefixes 001 through 111 must
also use a 64-bit interface identifier that is derived from the EUI-64 address. EUI-64
addresses are either assigned to a network adapter card or derived from IEEE 802
addresses.
IEEE 802 Addresses
Traditional interface identifiers for network adapters use a 48-bit address called an
IEEE 802 address. This 48-bit address is also called the physical, hardware, or media
access control (MAC) address.
Figure 2.10 shows the structure of the 48-bit IEEE 802 address.
Figure 2.10 The 48-bit IEEE 802 address

Defined bits within the IEEE 802 address are:
Universal/Local (U/L) The next-to-the low order bit in the first byte is used to
indicate whether the address is universally or locally administered.
Individual/Group (I/G) The low order bit of the first byte is used to indicate whether
the address is an individual address (unicast) or a group address (multicast).
27
IEEE EUI-64 Addresses

The IEEE EUI-64 address represents a new standard for network interface addressing.
The company ID is still 24-bits long, but the extension ID is 40 bits, creating a much
larger address space for a network adapter manufacturer. The EUI-64 address uses the
U/L and I/G bits in the same way as the IEEE 802 address.
Figure 2.11 shows the structure of the EIU-64 address.
Figure 2.11 The EUI-64 address

Mapping IEEE 802 Addresses to EIU-64 Addresses
To create an EUI-64 address from an IEEE 802 address, the 16 bits of 11111111
11111110 (0xFFFE) are inserted into the IEEE 802 address between the company ID
and the extension ID, as shown in Figure 2.12.
Figure 2.12 The conversion of an IEEE 802 address to an EUI-64 address
28
Mapping EUI-64 Addresses to IPv6 Interface Identifiers

To obtain the 64-bit interface identifier for IPv6 unicast addresses, the U/L bit in the
EUI-64 address is complemented (if it is a 1, it is set to 0; and if it is a 0, it is set to 1).
Figure 2.13 shows the conversion for a universally administered, unicast EUI-64
address.
Figure 2.13 The conversion of a universally administered, unicast EUI-64 address to

an IPv6 interface identifier
To obtain an IPv6 interface identifier from an IEEE 802 address, you must first map
the IEEE 802 address to an EUI-64 address, and then complement the U/L bit. Figure
2.14 shows this conversion process for a universally administered, unicast IEEE 802
address.
Figure 2.14 The conversion of a universally administered, unicast IEEE 802 address
to an IPv6 interface identifier
29
IPv6 and DNS

Enhancements to the Domain Name System (DNS) for IPv6 are described in RFC
1886 and consist of the following new elements:
Host address (AAAA) resource record
IP6.ARPA domain for reverse queries
The Host Address (AAAA) Resource Record
A new DNS resource record type, AAAA (called quad A), is used for resolving a
fully qualified domain name to an IPv6 address. It is comparable to the host address
(A) resource record used with IPv4. The resource record type is named AAAA (Type
value of 28) because 128-bit IPv6 addresses are four times as large as 32-bit IPv4
addresses. The following is an example of a AAAA resource record:
host1.iub.edu IN AAAA FEC0::2AA:FF:FE3F:2A1C
A host must specify either a AAAA query or a general query for a specific host name
in order to receive IPv6 address resolution data in the DNS query answer sections.
The IP6.ARPA Domain
The IP6.ARPA domain has been created for IPv6 reverse queries. Also called pointer
queries, reverse queries determine a host name based on the IP address. To create the
namespace for reverse queries, each hexadecimal digit in the fully expressed 32-digit
IPv6 address becomes a separate level in inverse order in the reverse domain
hierarchy.
For example, the reverse lookup domain name for the address
FEC0::2AA:FF:FE3F:2A1C (fully expressed as
FEC0:0000:0000:0000:02AA:00FF:FE3F:2A1C) is:
30
C.1.A.2.F.3.E.F.F.F.0.0.A.A.2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.C.E.F.IP6.ARPA.
The DNS support described in RFC 1886 represents a simple way to both map host
names to IPv6 addresses and provide reverse name resolution.
2.3.3 IPv4 vs. IPv6
Following table 2.2 shows the key differences between IPv4 and IPv6 protocol.
Introduction to IP Version 6 published by Microsoft Corporation dated February
2006 [12] where a detail description presented on IPv6 and its features and address
format etc. All this key issues are defined in the various Requests for Comments RFC lead by Internet Engineering Task Force IETF. The left side of the table
represents IPv4s features and the right side represents IPv6s features.
Table 2.2 Differences between IPv4 and IPv6 [12]
IPv4
IPv6
Source and destination addresses

are 32 bits (4 bytes) in length.
Source and destination addresses

are 128 bits (16 bytes) in length.
IPsec support is optional.
IPsec support is required
No identification of packet flow for Packet flow identification for QoS

QoS handling by routers is present handling by routers is included in
the IPv6 header using the Flow
within the IPv4 header.
Label field.
Fragmentation is done by both
routers and the sending host.
Fragmentation is not done by

routers, only by the sending host.
Header includes a checksum.
Header does not include a

checksum.
Header includes options.
All optional data is moved to IPv6

extension headers.
Address Resolution Protocol

(ARP) uses broadcast ARP
Request frames to resolve an IPv4
address to a link layer address.
ARP Request frames are replaced

with multicast Neighbor
Solicitation messages.
31
Table 2.2 Contd.

IGMP is replaced with Multicast
Internet Group Management
Protocol (IGMP) is used to manage Listener Discovery (MLD)
messages.
local subnet group membership.
ICMP Router Discovery is used to
determine the IPv4 address of the
best default gateway and is
optional.
ICMP Router Discovery is

replaced with ICMPv6 Router
Solicitation and Router
Advertisement messages and is
required.
Broadcast addresses are used to

send traffic to all nodes on a
subnet.
There are no IPv6 broadcast

addresses. Instead, a link-local
scope all-nodes multicast address
is used.
Must be configured either

manually or through DHCP.
Does not require manual

configuration or DHCP.
Uses host address (A) resource

records in the Domain Name
System (DNS) to map host names
to IPv4 addresses.
Uses host address (AAAA)

resource records in the Domain
Name System (DNS) to map host
names to IPv6 addresses.
Uses pointer (PTR) resource

records in the IN-ADDR.ARPA
DNS domain to map IPv4
addresses to host names.
Uses pointer (PTR) resource

records in the IP6.ARPA DNS
domain to map IPv6 addresses to
host names.
Must support a 576-byte packet

size (possibly fragmented).
Must support a 1280-byte packet

size (without fragmentation).
From the above table we understood the difference of both IPv4 and IPv6 protocol
and now we look in to the IPv4 addresses and IPv6 equivalents as under:
Table 2.3 IPv4 Addresses and IPv6 Equivalents [12]
IPv4 Address
IPv6 Address
Internet address classes
Not applicable in IPv6
Multicast addresses (224.0.0.0/4)
IPv6 multicast addresses (FF00::/8)
Broadcast addresses
Not applicable in IPv6
Unspecified address is 0.0.0.0
Unspecified address is ::
Loopback address is 127.0.0.1
Loopback address is ::1
Public IP addresses
Global unicast addresses
Private IP addresses (10.0.0.0/8,

172.16.0.0/12, and 192.168.0.0/16)
Site-local addresses (FEC0::/10)
Autoconfigured addresses
(169.254.0.0/16)
Link-local addresses (FE80::/64)
32
Table 2.3 Contd.

Text representation: Dotted
decimal notation
Text representation: Colon

hexadecimal format with
suppression of leading zeros and
zero compression. IPv4-compatible
addresses are expressed in dotted
decimal notation.
Network bits representation:

Subnet mask in dotted decimal
notation or prefix length
Network bits representation: Prefix

length notation only
DNS name resolution: IPv4 host

address (A) resource record
DNS name resolution: IPv6 host

address (AAAA) resource record
DNS reverse resolution: INADDR.ARPA domain
DNS reverse resolution: IP6.ARPA

domain
From the above tables we understood the difference of both IPv4 and IPv6 protocol
and IP addresses and now we look in to the differences of header fields of both
protocols as under:
Table 2.4 Comparing the IPv4 and IPv6 Headers [13]
IPv4 Header Field
IPv6 Header Field
Version
Same field but with different

version numbers.
Internet Header Length
Removed in IPv6. IPv6 does not

include a Header Length field
because the IPv6 header is always
a fixed size of 40 bytes. Each
extension header is either a fixed
size or indicates its own size.
Type of Service
Replaced by the IPv6 Traffic

Class field.
Total Length
Replaced by the IPv6 Payload

Length field, which only indicates
the size of the payload.
Identification
Fragmentation Flags
Fragment Offset
Removed in IPv6. Fragmentation

information is not included in the
IPv6 header. It is contained in a
Fragment extension header.
Time to Live
Replaced by the IPv6 Hop Limit

field.
33
Table 2.4 Contd.

Protocol
Replaced by the IPv6 Next

Header field.
Header Checksum
Removed in IPv6. In IPv6, bitlevel error detection for the entire

IPv6 packet is performed by the
link layer.
Source Address
The field is the same except that

IPv6 addresses are 128 bits in
length.
Destination Address
The field is the same except that

IPv6 addresses are 128 bits in
length.
Options
Removed in IPv6. IPv4 options

are replaced by IPv6 extension
headers.
The one new field in the IPv6 header that is not included in the IPv4 header is the
Flow Label field.
2.4
IPv4 TO IPv6 TRANSITION MECHANISMS AND SCENARIO
The designers of IPv6 recognize that the transition from IPv4 to IPv6 will take years
and that there might be organizations or hosts within organizations that will continue
to use IPv4 indefinitely. Therefore, while migration is the long-term goal, equal
consideration must be given to the interim coexistence of IPv4 and IPv6 nodes. There
are different types of node exist in the network such as [14] IPv4-only, IPv6-only,
IPv6/IPv4 node, IPv4 node and IPv6 node. There are different types of compatibility
addresses such as IPv4-compatible addresses, IPv4-mapped addresses, 6over4
addresses, 6to4 addresses, ISATAP addresses, Teredo addresses. To coexist with an
IPv4 infrastructure and to provide an eventual transition to an IPv6-only
infrastructure, the following mechanisms are used.
34
2.4.1 Dual IP Layer
The dual IP layer [15] is an implementation of the TCP/IP suite of protocols that
includes both an IPv4 Internet layer and an IPv6 Internet layer. This is the mechanism
used by IPv6/IPv4 nodes so that communication with both IPv4 and IPv6 nodes can
occur. A dual IP layer contains a single implementation of Host-to-Host layer
protocols such as TCP and UDP. All upper layer protocols in a dual IP layer
implementation can communicate over IPv4, IPv6, or IPv6 tunneled in IPv4.
Figure 2.15 A Dual IP Layer Architecture [15]
2.4.2 IPv6 Over IPv4 Tunneling
IPv6 over IPv4 tunneling is the encapsulation of IPv6 packets with an IPv4 header so
that IPv6 packets can be sent over an IPv4 infrastructure. Within the IPv4 header:
The IPv4 Protocol field is set to 41 to indicate an encapsulated IPv6 packet.
The Source and Destination fields are set to IPv4 addresses of the tunnel
endpoints. The tunnel endpoints are either manually configured as part of the
tunnel interface or are automatically derived from the sending interface, the
next-hop address of the matching route, or the source and destination IPv6
addresses in the IPv6 header.
35
Figure 2.16 IPv6 over IPv4 Tunneling [15]

For IPv6 over IPv4 tunneling, the IPv6 path maximum transmission unit (MTU) for
the destination is typically 20 less than the IPv4 path MTU for the destination.
However, if the IPv4 path MTU is not stored for each tunnel, there are instances
where the IPv4 packet will need to be fragmented at an intermediate IPv4 router. In
this case, IPv6 over IPv4 tunneled packet must be sent with the Dont Fragment flag
in the IPv4 header set to 0 [15].
In [14], defines the following tunneling configuration with which to tunnel IPv6
traffic between IPv6/IPv4 nodes over an IPv4 infrastructure:
Router-to-Router
Host-to-Router or Router-to-Host
Host-to-Host
Router-to-Router
In the router-to-router tunneling configuration, two IPv6/IPv4 routers connect two
IPv4 or IPv6 infrastructures over an IPv4 infrastructure. The tunnel endpoints span a
logical link in the path between the source and destination. The IPv6 over IPv4 tunnel
between the two routers acts as a single hop. Routes within each IPv4 or IPv6
36
infrastructure point to the IPv6/IPv4 router on the edge. For each IPv6/IPv4 router,
there is a tunnel interface representing the IPv6 over IPv4 tunnel and routes that use
the tunnel interface.
Figure 2.17: Router-to-Router Tunneling [15]

Examples of this tunneling configuration are:
An IPv6-only test lab that tunnels across an organizations IPv4 infrastructure to

reach the IPv6 Internet.
Two IPv6-only routing domains that tunnel across the IPv4 Internet.
A 6to4 router that tunnels across the IPv4 Internet to reach another 6to4 router or
a 6to4 relay router.
Host-to-Router and Router-to-Host

In the host-to-router tunneling configuration, an IPv6/IPv4 node that resides within an
IPv4 infrastructure creates an IPv6 over IPv4 tunnel to reach an IPv6/IPv4 router. The
tunnel endpoints span the first segment of the path between the source and destination
nodes. The IPv6 over IPv4 tunnel between the IPv6/IPv4 node and the IPv6/IPv4
router acts as a single hop.
On the IPv6/IPv4 node, a tunnel interface representing the IPv6 over IPv4 tunnel is
created and a route (typically a default route) is added using the tunnel interface. The
37
IPv6/IPv4 node tunnels the IPv6 packet based on the matching route, the tunnel
interface, and the next-hop address of the IPv6/IPv4 router.
In the router-to-host tunneling configuration, an IPv6/IPv4 router creates an IPv6 over

IPv4 tunnel across an IPv4 infrastructure to reach an IPv6/IPv4 node. The tunnel
endpoints span the last segment of the path between the source node and destination
node. The IPv6 over IPv4 tunnel between the IPv6/IPv4 router and the IPv6/IPv4
node acts as a single hop.
On the IPv6/IPv4 router, a tunnel interface representing the IPv6 over IPv4 tunnel is
created and a route (typically a subnet route) is added using the tunnel interface. The
IPv6/IPv4 router tunnels the IPv6 packet based on the matching subnet route, the
tunnel interface, and the destination address of the IPv6/IPv4 node.
Figure 2.18 shows host-to-router (for traffic traveling from Node A to Node B) and
router-to-host (for traffic traveling from Node B to Node A) tunneling.
Figure 2.18 Host-to-Router and Router-to-Host Tunneling [15]

Examples of host-to-router and router-to-host tunneling are:
An IPv6/IPv4 host that tunnels across an organizations IPv4 infrastructure to

reach the IPv6 Internet.
38
An ISATAP host that tunnels across an IPv4 network to an ISATAP router to

reach the IPv4 Internet, another IPv4 network, or an IPv6 network.
An ISATAP router that tunnels across an IPv4 network to reach an ISATAP host.
Host-to-Host
In the host-to-host tunneling configuration, an IPv6/IPv4 node that resides within an
IPv4 infrastructure creates an IPv6 over IPv4 tunnel to reach another IPv6/IPv4 node
that resides within the same IPv4 infrastructure. The tunnel endpoints span the entire
path between the source and destination nodes. The IPv6 over IPv4 tunnel between
the IPv6/IPv4 nodes acts as a single hop.
On each IPv6/IPv4 node, an interface representing the IPv6 over IPv4 tunnel is
created. Routes might be present to indicate that the destination node is on the same
logical subnet defined by the IPv4 infrastructure. Based on the sending interface, the
optional route, and the destination address, the sending host tunnels the IPv6 traffic to
the destination.
Figure 2.19 shows host-to-host tunneling.
Figure 2.19 Host-to-Host Tunneling [15]

Examples of this tunneling configuration are:
IPv6/IPv4 hosts that use ISATAP addresses to tunnel across an organizations

IPv4 infrastructure
IPv6/IPv4 hosts that use IPv4-compatible addresses to tunnel across an
39
organizations IPv4 infrastructure.

Types of Tunnels
In [14] defines the following types of tunnels:
Configured
Automatic
Configured Tunnels
A configured tunnel requires manual configuration of tunnel endpoints. In a
configured tunnel, the IPv4 addresses of tunnel endpoints are not derived from
addresses that are encoded in the IPv6 source or destination addresses or the next-hop
address of the matching route.
Typically, router-to-router tunneling configurations are manually configured. The

tunnel interface configuration, consisting of the IPv4 addresses of the tunnel
endpoints, must be manually specified along with static routes that use the tunnel
interface.
Automatic Tunnels
An automatic tunnel is a tunnel that does not require manual configuration. Tunnel
endpoints are determined by the use of logical tunnel interfaces, routes, and source
and destination IPv6 addresses.
40
CHAPTER 3
METHODOLOGY
In order to achieve the objectives, we adopted the following theoretical and

experimental steps as the methodology of the thesis work. The most of the theoretical
developments with literature review have been furnished in chapter 2. We mention
briefly the review works covering chapter 2 in section 2.1.
3.1
REVIEWING THE BASIC FUNCTIONALITIES AND PERFORMANCE

OF IPV4 AND IPV6
The basic functionalities and performance are reviewed in chapter 2.

3.2
STUDYING LAYERING APPROACHES AND ARCHITECTURES OF

IPV4 AND IPV6
The basic study is done to understand the Internet protocol version 4 and 6 and also its
features, functions, architecture and configuration in chapter 2. The OSI model and
architecture of IPv4 and IPv6 are compared to find out the differences, advantages
and disadvantages also in chapter 2. Transition mechanism techniques have been
studied in chapter 2.
3.3
LABORATORY SETUP FOR THE EXPERIMENT
In our test-lab, we arranged a set of hardware and software. Our test setup consists
two dual stack (IPv4/IPv6) routers: two Cisco routers model 2811. Dual stack
implementation specification can be found in [16]. We have two identical

workstations that were connected directly to the routers and were configured to be
separate networks. Each router supported two separate networks each. Both
workstations were equipped with Intel Pentium III 800 MHz processors, 256
megabytes of SDRAM PC133, two 40GB Maxtor 7200 RPM IDE hard drive, and
3COM 10/100 PCI network adapters. The workstations were loaded with Windows
2003 Standard Server and Red Hat Linux Enterprise version 4. Windows had the IPv4
stack as a standard protocol; however in order to get IPv6 support, an add-on package
was installed but in Linux was IPv6 loaded automatically. A number of testing tools
have been used for the experiment such as IPerf 1.7.0 [17] and PING. Detailed
specifications of Hardware, Software and testing tools are furnished in Appendix A, B
and D.
3.4
EXPERIMENTAL
Network system configurations for our experiment are provided in chapter 4 and 5
during the presentation and discussion of the experimental result found. Detailed of
the configurations are furnished in Appendix E. In our experiment, initially we
loaded required software configured the network system comprising of two PCs
connected to two separate Cisco 2811 routers with other necessaries accessories. We
carried out experiment, first to compute the bandwidth utilization performance. Data
were transmitted from one machine to another using the IPerf 1.7.0 tools for both
Windows and Linux platforms at various data sizes ranging from 128 KB to 61.44
MB.
The experiment was repeated for the computation of the round trip time
(latency) computation. The experiment was carried for both point-to-point and routerto-router architecture for the computation of BW utilization and round trip time
42
computation under both Windows and Linux platforms for variable data sizes as
mentioned above. Results obtained from the experiment are furnished in the next two
chapters 4 and 5 along with discussion and comments in chapter 6.
Presenting performance analysis through graph using log generated by the testing
tools and some logs are presented in Appendix F.
43
CHAPTER 4
IPv4 AND IPv6 PERFORMANCE ANALYSIS
In chapter 4, we explain two most key performance metrics. Then we present our testlab architectures and show results in numerical and graphical forms.
We have two different test-lab architectures. One is point-to-pint test-lab and the other
is router-to-router test-lab. In point-to-point test-lab, we used two workstations
connected through a cross UTP cat 5 cables and used Fast Ethernet LAN card in both
machines. In router-to-router test-lab, we used two workstations and each workstation
connected through cross UTP cat 5 cables with each router and router-to-router
connection is done through the same cross UTP cat 5 cable. Then we apply
performance testing under two different architectures over two Operating systems,
namely Windows and Linux.
4.1
PERFORMANCE METRICS
We use bandwidth utilization (throughput) and round trip time (latency) performance
metrics for measuring performance of IPv4 and IPv6 protocols. IPerf 1.7.0 and PING
tools are used to measure performance. The measurement interval was selected to be
60 seconds and the data sizes were about 128 KB to 61.44 MB. Each test was
repeated several times to obtain consistent results. Metrics parameters are in the
subsequent sections.

Bandwidth Utilization (throughput) [18] is the net carrying capacity of an element
corrected for overhead. Throughput is a theoretical value, calculated based on the
operating characteristics of a particular network. It represents the effective capacity of
a connection or service once all the things are considered. Following formula
illustrates this concept and how it relates to estimate the throughput of a device or
network link.
L = ( Q / K ) i d
i =1
where qL is the realized channel throughput at protocol layer, L, Q is the gross data
rate based on the transmission technology, K is the number of channels or traffic
flows, i is the channel protocol overhead at layer i, and d is the duplex factor. i is
the accumulated protocol loss over layer L and subtending layers.
4.1.2 Round Trip Time (Latency)

Round trip tine [18] is sometimes used interchangeably with response time, which is
the time taken between sending and reception of the data. Response time can be
thought of as round trip time from the perspective of the user, or the sending device.
For this reason, the same caveats that applied to round trip time also apply to
response. The PING program is often used to measure network response time. This is
an Internet control message protocol (ICMP), message that sends packets to a specific
host at an IP address and times the response. Although this program can be indicative
of network-based processing such as connection setup, routing, and transmission
delay, it may not be truly reflective of overall response from a service perspective.
45
Server processing, application processing, and data transfer from storage should also
be included.
4.2
POINT-TO-POINT TEST-LAB PERFORMANCE RESULTS
The tests with minimum point-to-point architecture where two computers are directly
connected through Unshielded Twisted Pair cross Ethernet cable; its hardware
configuration was mentioned in chapter 3. We install operating systems and both
protocols stack IPv4 and IPv6 in both machines and we configure IP addresses from
the same subnet 192.168.20/24 and 11:11:11:11/64 for both computers depicted in
Figure 4.1.
Figure 4.1 Point-to-Point Test-Labs Architecture; two computers are directly

connected through unshielded twisted pair cross Ethernet cable

Figure 4.2 shows that both IPv4 and IPv6 protocols under Windows perform quite
closely. IPv6 incurs 1 to 2% more overhead in this type of data size.
(Mbits/s)
Bandwidth Utilization
Performance of TCP in IPv4 and IPv6 under Windows

100
90
80
70
60
50
40
30
20
10
0
128
256
384
512
640
768
896
1024
1152
1280
1408
Packet Size (KB)

TCP/IPv4 W2K3
TCP/IPv6 W2K3
Figure 4.2 Bandwidth Utilization Results for IPv4/IPv6 under Windows; data sizes
ranging from 128KB to 1.408MB
46
Figure 4.3 shows that IPv4 performs slightly better than IPv6 protocols under
Windows. IPv6 incurs around 3% more overhead in the bigger data sizes.
(Mbits/s)

95
94
93
92
91
90
89
5120
10240
15360
20480
25600
30720
35840
40960
46080
51200
56320
61440
Packet Size (KB)

TCP/IPv4 W2K3
TCP/IPv6 W2K3
ranging from 5.12 to 61.44 MB
Figure 4.4 shows that IPv4 performs slightly better than IPv6 protocols under Linux.
IPv6 incurs around 2% more overhead in the smaller data sizes.
(Mbits/s)
Performance of TCP in IPV4 and IPv6 under Linux

100
98
96
94
92
90
128
256
384
512
640
768
896
1024
1152
1280
1408
Packet Size (KB)

TCP/IPv4 Linux
TCP/IPv6 Linux
Figure 4.4 Bandwidth Utilization Results for IPv4/IPv6 under Linux; data sizes
47
Figure 4.5 shows that IPv4 performs slightly better than IPv6 protocols under Linux.
IPv6 incurs around 2 to 5% more overhead in the bigger data sizes.
(Mbits/s)
Performance of TCP in IPv4 and IPv6 under Linux

96
95
94
93
92
91
5120
10240
15360
20480
25600
30720
35840
40960
46080
51200
56320
61440
Packet Size (KB)

TCP/IPv4 Linux
TCP/IPv6 Linux
ranging from 5.12 to 61.44MB
Figure 4.6 shows that IPv4 under Linux performs better than IPv4 under Windows
initially, but when data sizes grow bigger the performance became closer. Here, we
find slight differences between Windows and Linux with the same IPv4 protocol. It is
most probably due to the algorithmic differences and/or time acknowledgement
differences in Windows and Linux.
(Mbits/s)
Performance of TCP in IPv4 under Windows and Linux

100
90
80
70
60
50
40
30
20
10
0
128
256
384
512
640
768
896
1024
1152
1280
1408
Packet Size (KB)

TCP/IPv4 W2K3
TCP/IPv4 Linux
Figure 4.6 Bandwidth Utilization Results for IPv4 under Linux and Windows; data
sizes ranging from 128 KB to 1.408 MB
48
Figure 4.7 shows that again IPv6 under Linux performs better than IPv6 under
Windows initially, but when data sizes grow bigger the performance became closer.
Here, we find slight differences between Windows and Linux with the same IPv6
protocol as shown in Fig. 4.6 (chapter 4). It is most probably due to the algorithmic
differences and/or time acknowledgement differences in Windows and Linux.
(Mbits/s)

100
90
80
70
60
50
40
30
20
10
0
128
256
384
512
640
768
896
1024
1152
1280
1408
Packet Size (KB)

TCP/IPv6 W2K3
TCP/IPv6 Linux
sizes ranging from 128KB to 1.408MB
Figure 4.8 shows that initially IPv4 under Linux performs better than IPv4 under
Windows and in the middle portion of the data sizes, it becomes quite close. Finally,
Linux gains around 2% more bandwidth. Here, we find slight performance differences
between Windows and Linux with the same IPv4 protocol as shown in Fig. 4.6 and
4.7.
(Mbits/s)

95.5
95
94.5
94
93.5
93
92.5
92
5120
10240
15360
20480 25600
30720 35840
40960 46080
51200
56320 61440
Packet Size (KB)

TCP/IPv4 W2K3
TCP/IPv4 Linux
sizes ranging from 5.12 to 61.144 MB
49
Figure 4.9 shows that initially again IPv6 under Linux performs better than IPv6
under Windows, but when data sizes grow bigger the performance became closer.
Here, we find slight differences between Windows and Linux with the same IPv6
protocol as shown in Figs. 4.6, 4.7 and 4.8. Now, it is clear that there are some
architectural differences in Windows and Linux.
(Mbits/s)

93.5
93
92.5
92
91.5
91
90.5
90
89.5
5120
10240
15360 20480
25600
30720
35840
40960
46080 51200
56320
61440
Packet Size (KB)

TCP/IPv6 W2K3
TCP/IPv6 Linux
sizes ranging from 5.12 to 61.44 MB
Figure 4.10 gives a picture of overall performance of IPv4 and IPv6 under Linux and
Windows. Though, IPv6 performs poorer than IPv4 in both platforms due to overhead
factor, IPv4 have slight performance differences in the both platforms due to
architectural factors of OS manufacturer.
(Mbits/s)
Performance of TCP in IPv4 and IPv6 under Windows and Linux

96
95
94
93
92
91
90
89
5120
10240
15360
20480
25600
30720
35840
40960
46080
51200
56320
61440
Packet Size (KB)

TCP/IPv4 W2K3
TCP/IPv4Linux
TCP/IPv6 W2K3
TCP/IPv6 Linux
Figure 4.10 Bandwidth Utilization Results for IPv4/IPv6 under Linux and Windows;
data sizes ranging from 5.12 to 61.44 MB
50
closely. IPv6 incurs 1 to 2% more overhead in smaller data size. It can transfer data at
a faster rate due to connectionless protocol and it does not acknowledge.
(Mbits/s)
Performance of UDP in IPv4 and IPV6 under Windows

100
90
80
70
60
50
40
30
20
10
0
128
256
384
512
640
768
896
1024
1152
1280
1408
Packet Sized (KB)

UDP/IPv4 W2K3
UDP/IPv6 W2K3

Figure 4.12 shows that both IPv4 and IPv6 protocols perform at the same level of
efficiency under Windows. Actually, Windows gives millisecond time resolution
(mS) unit in computation. So, it is not possible to capture fraction of mS in the results
of round trip time to figure out actual IPv6 overhead.
Latency - RTT (ms)
Performance of Latency in IPv4 and IPv6 under Windows

14
12
10
8
6
4
2
0
5120
10240
15360
20480
25600
30720
35840
40960
46080
51200
56320
61440
Packet Size (Bytes)

TCP/IPv4 W2K3
TCP/IPv6 W2K3
Figure 4.12 Round Trip Time Results for IPv4/IPv6 under Windows; data sizes
51
Figure 4.13 shows that both IPv4 and IPv6 protocols perform quite closely under
Linux. IPv6 incurs 1.8 to 2.9% more overhead over all data sizes.
Latency - RTT (ms)
Performance of Latency in IPv4 and IPv6 under Linux

12
10
8
6
4
2
0
5120
10240
15360
20480
25600
30720
35840
40960
46080
51200
56320
61440
Packet Size (Bytes)

TCP/IPv4 Linux
TCP/IPv6 Linux
Figure 4.13 Round Trip Time Results for IPv4/IPv6 under Linux; data sizes ranging
from 5.12 to 61.44 MB
Figure 4.14 gives a picture of overall round trip time performance of both IPv4 and
IPv6 protocols under Linux and Windows. If we look closely, we can see that IPv4
under Linux performs the best and worst for IPv6 under Windows.
Latency - RTT (ms)
Performance of Latency in IPv4 and IPv6 under Windows and Linux

14
12
10
8
6
4
2
0
5120
10240
15360
20480
25600
30720
35840
40960
46080
51200
56320
61440
Packet Size (bytes)

TCP/IPv4 W2K3
TCP/IPv6 W2K3
TCP/IPv4 Linux
TCP/IPv6 Linux
Figure 4.14 Round Trip Time Results for IPv4/IPv6 under Linux and Windows; data
sizes ranging from 5.12 to 61.44MB
52
4.3
ROUTER-TO-ROUTER TEST-LAB PERFORMANCE RESULTS
This is a real world solution, where router-to-router communicates. In this

architecture, we used two directly connected routers through unshielded twisted pair
cross Ethernet cable and two directly connected computers to each router through
unshielded twisted pair cross Ethernet cable. Its hardware configuration is already
described in chapter 3. We install operating systems and both protocols stack IPv4
and IPv6 in both the machines and the routers. We configured IP addresses from two
different subnet masks 192.168.20/24 and 192.168.30.0/24 respectively in IPv4
environment for each router sites and another series 192.168.50.0/252 for router-torouter WAN link. After that, we also configured IP address 11:11:11:11/64 and
22:22:22:22/64 in IPv6 environment for each router sites and another series
33:33:33:33/64 for router to router WAN link. Router to router architecture is
depicted in figure 4.15.
Figure 4.15 Router-to-Router Test-Labs Architecture; two computers are directly

connected through unshielded twisted pair cross Ethernet cable to each router and two
routers are directly connected through unshielded twisted pair cross Ethernet cable as
WAN connection
53

closely. IPv6 incurs around 14% more overhead in this type of data sizes and it was 1
to 2% as shown in Fig. 4.2 for Point-to-Point architecture.
(Mbits/s)

100
90
80
70
60
50
40
30
20
10
0
128
256
384
512
640
768
896
1024
1152
1280
1408
Packet Size (KB)

TCP/IPv4 W2K3
TCP/IPv6 W2K3
Figure 4.17 shows that IPv4 performs better than IPv6 under Windows. IPv6 incurs
around 19% more overhead in all data sizes and it was 3% in Fig. 4.3 for Point-toPoint architecture.
(Mbits/s)

100
90
80
70
60
50
40
30
20
10
0
5120
10240
15360
20480
25600
30720
35840
40960
46080
51200
56320
61440
Packet Size (KB)

TCP/IPv4 W2K3
TCP/IPv6 W2K3
54
Figure 4.18 shows that IPv4 performs better than IPv6 under Linux. IPv6 incurs
around 9% more overhead in all data sizes and it was around 2% in Fig. 4.4 for Pointto-Point architecture.
(Mbits/s)

90
85
80
75
70
65
128
256
384
512
640
768
896
1024
1152
1280
1408
Packet Size (KB)

TCP/IPv4 Linux
TCP/IPv6 Linux
Figure 4.19 shows that IPv4 performs better than IPv6 under Linux. IPv6 incurs
around 12% more overhead in the bigger data sizes and it was 2 to 5% in Fig. 4.5 for
Point-to-Point architecture.
(Mbits/s)

85
80
75
70
65
5120
10240
15360
20480
25600
30720
35840
40960
46080
51200
56320
61440
Packet Size (KB)

TCP/IPv4 Linux
TCP/IPv6 Linux
55
Figure 4.20 gives a picture of overall performance of IPv4 and IPv6 under Linux and
Windows. Though, IPv6 performs poorer in comparison to IPv4 in both platforms due
to overhead constraint, IPv4 also have slight performance differences in both the
platforms due to OS manufacturer architectural philosophy. Linux performs better
than Windows in all cases.
(Mbits/s)
Performance of TCP in IPv4/IPv6 under Windows and Linux

85
80
75
70
65
60
5120
10240
15360
20480
25600
30720
35840
40960
46080
51200
56320
61440
Packet Size (KB)

TCP/IPv4 W2K3
TCP/IPv4 Linux
TCP/IPv6 W2K3
TCP/IPv6 Linux
Figure 4.20 Bandwidth Utilization Results for IPv4/IPv6 under Linux and Windows;
data sizes ranging from 5.12 to 61.44MB
Figure 4.21 shows that both IPv4 and IPv6 under Windows performs quiet close. IPv6
incurs around 7% more overhead in smaller data sizes. It can transfer data faster due
to connection less protocol and it doesnt acknowledge. It was 1 to 2% in Fig. 4.11
Point-to-Point architecture.
(Mbits/s)
Performance of UDP in IPv4/IPv6 under Windows

70
60
50
40
30
20
10
0
128
256
384
512
640
768
896
1024
1152
1280
1408
Packet Size (KB)

UDP/IPv4 W2K3
UDP/IPv6 W2K3
56

Figure 4.22 shows that both IPv4 and IPv6 protocols are performing quite closely
under Windows. Actually, Windows gives results in millisecond time resolution (mS)
unit. So, it is not possible to capture fraction results of round trip time to figure out
actual IPv6 overhead. However, IPv6 incurs around 7% more overhead.
Latency - RTT (ms)
Performance of Latency in IPv4/IPv6 under Windows

14
12
10
8
6
4
2
0
5120
10240
15360
20480
25600
30720
35840
40960
46080
51200
56320
61440
Packet Size (KB)

TCP/IPv4 W2K3
TCP/IPv6 W2K3
Figure 4.22 Round Trip Time Results for IPv4/IPv6 under Windows; data sizes
Figure 4.23 shows that both IPv4 and IPv6 protocols quite closely under Linux. IPv6
incurs around 13% more overhead in small data sizes and around 4% in bigger data
sizes. It was 1.8 to 2.9% as shown in Figure 4.13 for Point-to-Point architecture.
Latency - RTT (ms)
Performance of Latency IPv4/IPv6 under Linux

14
12
10
8
6
4
2
0
5120
10240
15360
20480
25600
30720
35840
40960
46080
51200
56320
61440
Packet Size (KB)

TCP/IPv4 Linux
TCP/IPv6 Linux
Figure 4.23 Round Trip Time Results for IPv4/IPv6 under Linux; data sizes ranging
from 5.12 to 61.44MB
57
Figure 4.24 gives a picture of overall round trip time performance of both IPv4 and
IPv6 protocols under Linux and Windows. If we look closely we can see that IPv4
under Linux performs the best and worst for the IPv6 under Windows.
Latency - RTT (ms)
Performance of Latency in IPv4/IPv6 under Windows and Linux

14
12
10
8
6
4
2
0
5120
10240
15360
20480
25600
30720
35840
40960
46080
51200
56320
61440
Packet Size (KB)

TCP/IPv4 Linux
TCP/IPv6 Linux
TCP/IPv4 W2K3
TCP/IPv6 W2K3
Figure 4.24 Round trip Time Results for IPv4/IPv6 under Linux and Windows; data
4.4
CONCLUSION
After analyzing all the results for above cases, we find that IPv6 incurs around 1 to
5% and 9 to 20% more overhead in point-to-point and router-to-router architecture
respectively under both Windows and Linux platforms. Though, theoretically IPv4
and IPv6 overhead difference benchmarking is 1.44%, but we find slightly more due
to its lack of maturity and still it is in developing stage. We also find that, there is a
performance difference between Linux and Windows in both IPv4 and IPv6
implementations due to technical and architectural philosophy of the OS
manufacturer. It is clear to us that in all cases, Linux performs better than Windows
due to the fact that kernel buffer allocation strategies for Windows are less efficient
compared to Linux counterpart [19].
58
CHAPTER 5
IPv4 TO IPv6 MIGRATION MECHANISMS AND
PERFORMANCE ANALYSIS
In this chapter, we analyze two types of transition mechanisms, one is host-to-host

and the other is router-to-router tunneling. This will be a real scenario whenever we
will deploy IPv6 in IPv4 infrastructure. We apply the same performance metrics in
both the cases what we explained in chapter 4. In this test-lab, we used the same
machine and router what we used in the last test-lab and we just configured additional
new tunneling operations under two operating systems for host-to-host and
router-to-router tunneling.
5.1
HOST-TO-HOST AND ROUTER-TO-ROUTER TUNNELING

PERFORMANCE RESULTS
Figure 5.1 shows the architecture of host-to-host tunneling under both Windows and
Linux platforms. In host-to-host tunneling, encapsulation occurs at the source end and
de-capsulation occurs at the destination end and in between a virtual tunnel circuit is
created in the sea of IPv4 to exchange data between two IPv6 enabled ends.
Figure 5.1 Host-to-Host Tunneling Architecture
Figure 5.2 shows the architecture of router-to-router Tunneling under Cisco platform.
In router-to-router tunneling, encapsulation occurs at the senders router end and decapsulation occurs at the recipients router end and in between the two routers, a
virtual tunnel circuit is created in the sea of IPv4 infrastructure to exchange data
between two IPv6 enabled ends.
Figure 5.2 Router-to-Router Tunneling Architecture

Figure 5.3 shows that IPv6 encapsulated in IPv4, designated as IPv4 (IPv6) router-torouter Tunneling performs better than the host-to-host Tunneling. IPv4 (IPv6) Hostto-Host Tunneling incurs 16% more overhead.
(Mbits/s)
Performance of TCP in IPv4(IPv6) Tunneling under Windows

100
90
80
70
60
50
40
30
20
10
0
5120
10240
15360
20480
25600
30720
35840
40960
46080
51200
56320
61440
Packet Size (KB)

TCP/IPv4(IPv6) W2K3 Host-2-Host Tunnel
TCP/IPv4(IPv6) W2K3 Router-2-Router Tunnel
Figure 5.3 Bandwidth Utilization Results for IPv4 (IPv6) Host-to-Host and Router-toRouter Tunneling under Windows and Cisco; data sizes ranging from 5.12 to
61.44MB
60
Figure 5.4 depicts that IPv4 (IPv6) router-to-router Tunneling performs better than
host-to-host Tunneling, and even than the IPv6 routing architecture. IPv4 (IPv6) hostto-host Tunneling incurs around 5% more overhead than IPv6 routing infrastructure
and router-to-router Tunneling getting around 12% more advantages from IPv6
routing infrastructure.
(Mbits/s)
Perform ance of TCP in IPv4(IPv6) Tunneling under Window s

100
90
80
70
60
50
40
30
20
10
0
5120
10240
15360
20480
25600
30720
35840
40960
46080
51200
56320
61440
Packet Size (KB)

TCP/IPv6 W2K3 Router-2-Router
Figure 5.4 Bandwidth Utilization Results for IPv4 (IPv6) host-to-host, router-to-router
Tunneling and IPv6 router-to-router infrastructure under Windows and Cisco; data
Figure 5.5 again shows that IPv4 (IPv6) router-to-router Tunneling performs better
than host-to-host Tunneling in Linux. It is clear that IPv4 (IPv6) host-to-host
Tunneling incurs more overhead than router-to-router Tunneling and the tunneling
rate is 18%.
Bandwidth
Utilization (Mbits/s)
Performance of TCP in IPv4(IPv6) Tunneling under Linux

100
90
80
70
60
50
40
30
20
10
0
5120
10240
15360
20480
25600
30720
35840
40960
46080
51200
56320
61440
Packet Size (KB)

TCP/IPv4(IPv6) Linux Host-2-Host Tunnel
TCP/IPv4(IPv6) Linux Router-2-Router Tunnel
Figure 5.5 Bandwidth Utilization Results for IPv4(IPv6) host-to-host and router-torouter Tunneling under Linux and Cisco; data sizes ranging from 5.12 to 61.44MB
61
Figure 5.6 depicts that IPv4 (IPv6) router-to-router Tunneling performs better than the
host-to-host Tunneling and even IPv6 routing architecture. IPv4 (IPv6) host-to-host
Tunneling incurs around 4% more overhead from IPv6 routing infrastructure and
router-to-router Tunneling getting around 15% more advantage over IPv6 routing
infrastructure.
(Mbits/s)
Performance of TCP in IPv4(IPv6) Tunneling under Linux

100
90
80
70
60
50
40
30
20
10
0
5120
10240 15360
20480 25600 30720 35840 40960 46080
51200 56320 61440
Packet Size (KB)

TCP/IPv6 Linux Router-2-Router
Figure 5.6 Bandwidth Utilization Results for IPv4 (IPv6) host-to-host, router-to-router
Tunneling and IPv6 router-to-router infrastructure under Linux and Cisco; data sizes
Figure 5.7 gives a picture of overall performance of IPv4 (IPv6) tunneling under
Linux, Windows with Cisco. Here, we find that Linux with router-to-router Tunneling
performs better than Windows tunneling. We also find that router-to-router Tunneling
performs better than the host-to-host tunneling, because of OS incurs more overhead
than IOS (Internetworking Operating System) in router.
(Mbits/s)
Perform ance of TCP in IPv4(IPv6) Tunneling under Window s and Linux

100
90
80
70
60
50
40
30
20
10
0
5120
10240
15360
20480
25600
30720
35840
40960
46080
51200
56320
61440
Packet Size (KB)

TCP/IPv6 W2K3 Router-2-Router
TCP/IPv6 Linux Router-2-Router
Figure 5.7 Bandwidth Utilization Results for IPv4(IPv6) host-to-host, router-to-router

Tunneling and IPv6 router-to-router infrastructure under Linux, Windows with Cisco;
62

Figure 5.8 shows that IPv4 (IPv6) router-to-router Tunneling performs better than the
host-to-host Tunneling under Windows. host-to-host tunneling incurs around 35%
more overhead.
Latency - RTT (ms)
Performance of Latency in IPv4(IPv6) Tunneling under Windows

30
25
20
15
10
5
0
5120
10240
15360
20480
25600
30720
35840
40960
46080
51200
56320
61440
Packet Size (KB)

Figure 5.8 Round trip Time Results for IPv4 (IPv6) Tunneling under Windows and
Cisco; data sizes ranging from 5.12 to 61.44MB
Figure 5.9 again show that IPv4 (IPv6) router-to-router Tunneling performs better
than the host-to-host Tunneling under Linux like Windows. The performance is quite
close for smaller size data but bigger size data it incurs more overhead. host-to-host
tunneling incurs around 33% more overhead.
Latency - RTT (ms)
Performance of Latency in IPv4 (IPv6) Tunneling under Linux

25
20
15
10
5
0
5120
10240
15360
20480
25600
30720
35840
40960
46080
51200
56320
61440
Packet Size (KB)

Figure 5.9 Round trip Time Results for IPv4 (IPv6) Tunneling under Linux and Cisco;
63
Figure 5.10 gives a picture of IPv4 (IPv6) router-to-router and host-to-host Tunneling
performances. Here, Linux shows better round trip time than Windows. We find that
Linux incurs lower delay time to exchange data over the net due to the fact that its
kernel performs more efficiently than that of Windows [19].
Latency - RTT
(ms)
Performance of Latency in IPv4(IPv6) Tunneling under Linux and Windows

30
20
10
0
5120
10240
15360
20480
25600
30720
35840
40960
46080
51200
56320
61440
Packet Size (KB)

Figure 5.10 Round trip Time Results for IPv4 (IPv6) Tunneling under Linux,
Windows and Cisco platforms; data sizes ranging from 5.12 to 6144MB
5.2
CONCLUSION
In conclusion we infer our observation that router-to-router tunneling performs better

than the host-to-host tunneling in all cases. We think that host-to-host incurs more
overhead than router-to-router, because router device works at layer 3 (network
layer), where memory, storage and processor are dedicatedly used for it on the other
hand for host-to-host case all the 7 layers are used.
64
CHAPTER 6
RESULTS AND DISCUSSIONS
6.1
INTRODUCTION
In this chapter, we furnish experimental results of the performance indicators in the

form of bandwidth utilization and round trip time computation for both IPv4 and
IPv6. We provide results and discussions only on the point-to-point and router-torouter tunneling architectures.
6.2
RESULTS AND DISCUSSIONS
6.2.1 Bandwidth Utilization for Point-to-Point Architecture
Under Windows, bandwidth utilization results for IPv4 and IPv6 with data size
ranging from 128 KB to 1.408 MB as shown in Fig. 4.2 (Chapter 4) shows that the
performance indicators are quite close. In comparison to IPv4, the IPv6 incurs 1 to 2%
more overhead in this type of data sizes. It incurs around 3% more overhead for
bigger data sizes ranging from 5.12 to 61.44 MB as shown in Fig. 4.3 (Chapter 4).
As the header size of IPv6 is bigger than that of IPv4, probably IPv6 incurs more
overhead than IPv4. More overhead results for bigger message of bigger data size
happens due to bigger number of data packets and its corresponding
acknowledgement time used up by the protocol in comparison to smaller message of
smaller data sizes.
Under Linux, bandwidth utilization results of IPv6 incurs around 2% more overhead
in the smaller data sizes ranging from 128 KB to 1.408 MB as shown in Fig. 4.4
(Chapter 4). For 5.12 to 61.44 MB data sizes Fig. 4.5 (Chapter 4), we see that IPv4
performs slightly better than IPv6 protocols. IPv6 incurs 2 to 5% more overhead for
the bigger data sizes.
As IPv6 has bigger header than IPv4 header, in Linux also, IPv6 incurs more
overhead than IPv4.
We see that IPv6 under Linux performs better than under Windows (see Fig. 4.7,
Chapter 4) for all kinds of data sizes, but at smaller data size level, performance of
Windows is poorer. As the data size grows bigger and bigger, the difference becomes
lesser and lesser as shown in Fig. 4.7 (Chapter 4). The reason may be perhaps due to
the use of different algorithms and time acknowledgement differences in Windows
and Linux platforms.
It is surprising to see in Fig. 4.9 (Chapter 4) that for data sizes between 25 to 45 MB,
Windows performs better. It is difficult to make comments on these results at this
moment, because our experimental results are confined within point-to-point level
only. Further study is required in bigger networking environment to see whether
similar results repeat.
6.2.2 Round Trip Time Computation for Point-to-Point Architecture

As seen in Fig. 4.12 (Chapter 4), both IPv4 and IPv6 protocols perform at the same
level of efficiency under Windows. Actually, Windows permits millisecond level time
resolution only. So, it is difficult to capture time in microsecond level directly for
66
smaller sizes data. But for bigger size data transmission, the fractions of millisecond
level time are manifested in the total count. Thus for latency computation, we used the
indirect way of time counting. The results for round trip time to figure out actual IPv6
overhead appear in Fig. 4.12 (Chapter 4).
As shown in Fig. 4.13 (Chapter 4), we see that IPv4 and IPv6 perform quite closely
under Windows. IPv6 incurs 1.8 to 2.9% more overhead for all ranges of data sizes
(see Fig. 4.13, Chapter 4), which matches with theoretical speculations also. IPv6
header is 20 bytes bigger than that of IPv4 and the difference happens to be bigger for
bigger overhead.
6.2.3 Bandwidth Utilization for Router-to-Router Architecture
Under Windows, bandwidth utilization results for data size ranges from 1.28 to 1.408
MB, which is shown in Fig. 4.16 (Chapter 4). It appears that IPv6 incurs a 14% more
overhead in this type of data size, which is 1 to 2% only for point-to-point architecture
as shown Fig. in 4.2 (Chapter 4). It is seen in Fig. 4.17 (Chapter 4) that IPv4 performs
better than IPv6 for data sizes ranging from 5.12 to 61.44 MB. For all ranges of data
size used in our experiment router-to-router case, IPv6 incurs around 19% overhead,
which is only 3% for point-to-point architecture as shown in Fig. 4.3 (Chapter 4).
Perhaps more routers contribute to additional overhead which incurs more overhead
than point-to-point architecture.
Under Linux, bandwidth utilization results for data sizes of 128 KB to 1.408 MB are
shown in Fig. 4.18 (Chapter 4). It is seen that IPv4 performs better than IPv6 and it
67
incurs around 9% overhead for all data sizes used in our experiments. It is to compare
that the overhead is only 2% for point-to-point architecture as appears in Fig. 4.4
(Chapter 4). For larger data sizes ranging from 5.12 to 61.440 MB, Fig. 4.19 (Chapter
4) shows that IPv4 performs better than IPv6. IPv6 incurs 12% overhead for larger
data sizes, which is lies between 2 to 5% point-to-point architecture as shown in
Figure 4.5 (Chapter 4).
Perhaps more routers contribute to additional overhead which incurs more overhead
than point-to-point architecture.
6.2.4 Round Trip Time Computation for Router-to-Router Architecture

Under Windows, for data sizes between 5.12 to 61.44 MB, Fig. 4.22 (Chapter 4)
shows that both IPv4 and IPv6 perform quite closely. IPv6 incurs around 7% more
overhead than IPv4. Here, perhaps router adds extra overhead with data transmission
in IPv6 which results to bigger values than IPv4 in total overhead count.
Under Linux, for data sizes between 5.120 to 61.440 MB, Fig. 4.23 (Chapter 4) shows
that both IPv4 and IPv6 perform quite closely. At the starting end of the data size in
router-to-router architecture, IPv6 incurs around 13% more overhead, which falls to
4% around the finishing end of the data size. This overhead is 1.8 to 2.9% only for
point-to-point architecture as shown in Fig. 4.13 (Chapter 4). Here also, the reason is
the same for the increase of overhead incurred by IPv6 as in the previous case. Here
only platform is different.
68
6.2.5 Bandwidth Utilization for Host-to-Host and Router-to-Router Tunneling

Architecture
Under Windows, bandwidth utilization results for IPv6 data transmission through
IPv4 environment for host-to-host in Windows and router-to-router with Cisco router
tunneling at data sizes, between 5.12 and 61.44 MB are shown in Fig. 5.3 (Chapter 5).
It is seen that router-to-router tunneling performs better than the host-to-host
tunneling. The host-to-host tunneling incurs 16% more overhead.
Packet encapsulation occurred under operating system in host-to-host tunneling
architecture and it uses double encapsulation (IPv6 header in IPv4 header) from
transport layer whereas router-to-router architecture encapsulates from network layer.
So, router-to-router tunneling incurs less overhead than the host-to-host tunneling.
Under Windows, bandwidth utilization results for IPv4/IPv6 are computed in 3 ways.
First one is the host-to-host tunneling, second one is the router-to-router tunneling and
third one is the IPv6 router-to-router direct transmission under Windows with Cisco
router at data sizes, from 5.12 to 61.44 MB, which are shown in Fig. 5.4 (Chapter 5).
It is seen that for the first case of IPv4/IPv6, the performance is the best for router-torouter tunneling, having bandwidth utilization value of 69.9 Mbps out of 100 Mbps.
For the second one, host-to-host tunneling bandwidth utilization is 58.79 Mbps, which
incurs 15.9% more overhead than the first case. For the third case, the performance
has been found to be the worst, counting to 12% more overhead than the first case.
69
The router-to-router tunneling is even better than direct IPv6 router-to-router

transmission. Router-to-router tunneling encapsulation overhead is less than IPv6
router-to-router direct transmission overhead.
Under Linux, bandwidth utilization results for IPv6 data transmission through IPv4
environment for host-to-host in Linux and router-to-router tunneling with Cisco router
at data sizes, between 5.12 and 61.44 MB are shown in Fig. 5.5 (Chapter 5). It is also
seen router-to-router tunneling performs better than the host-to-host tunneling like
Windows platform. The host-to-host tunneling incurs 18% more overhead.
The router-to-router tunneling is even better than direct IPv6 router-to-router
transmission. Router-to-router tunneling encapsulation overhead is less than IPv6
router-to-router direct transmission overhead.
Under Linux, bandwidth utilization results for IPv4/IPv6 are computed in 3 ways.
First one is the host-to-host tunneling, second one is the router-to-router tunneling and
the third one is the IPv6 router-to-router direct transmission under Linux with Cisco
router at data sizes, from 5.12 to 61.44 MB as shown in Fig. 5.6 (Chapter 5). It is
seen that for the first case of IPv4/IPv6 router-to-router tunneling, the performance is
the best, having bandwidth utilization value of 83.52 Mbps. For the second one, hostto-host tunneling incurs 17% more overhead than the first case. For the third case, the
performance has been found to be the worst, counting to 15% more than the first case.
70
6.2.6 Round Trip Time Computation for Host-to-Host and Router-to-Router

Tunneling Architecture
Under Windows with Cisco router, round trip time results for IPv4/IPv6 tunneling for
data sizes, from 5.12 to 61.44 MB are shown in Fig. 5.8 (Chapter 5). It is seen that
IPv4/IPv6 router-to-router tunneling performs better. The host-to-host tunneling under
Windows incurs 35% more overhead than the router-to-router tunneling case.
Here, perhaps host-to-host tunneling adds extra encapsulation overhead than routerto-router tunneling.
Under Linux with Cisco router, latency results for IPv4/IPv6 tunneling for data sizes,
from 5.12 to 61.44 MB are shown in Fig. 5.9 (Chapter 5). It is seen that IPv4/IPv6
router-to-router tunneling performs better. The host-to-host tunneling under Linux
incurs 33% more overhead than the router-to-router tunneling case.
Here, perhaps host-to-host tunneling adds extra encapsulation overhead than routerto-router tunneling.
71
CHAPTER 7
CONCLUSION AND SCOPE FOR FUTURE WORKS
7.1
CONCLUSION
In the present thesis, we carried out a series of experiments to compare the

performance analysis of IPv4 and IPv6 stack protocols under Windows 2003 Server
and Red Hat Linux Enterprise Version 4 platforms. We measured the performance
parameters for the protocols in terms of bandwidth utilization and RTT (latency)
computation for host-to-host and router-to-router architectures. We also carried out
experiments on tunneling of IPv6 packets through IPv4 environment.
Performance analysis for point-to-point architecture was carried out to see only the
normal operational characteristics of both the protocols. But our experiments are
mostly focused on the router-to-router bandwidth utilization and RTT (latency)
performance measurements only.
We found that tunneling under router-to-router architecture is always superior to that

in host-to-host architecture in all the experiments.
Another observation is that under Linux platform, bandwidth utilization is better than
that under Windows.
Interestingly, we find from our experimental results that the bandwidth utilization and
RTT (latency) parameters of IPv4 are superior to those of IPv6 protocols. For this
case, we infer that IPv6 results are poorer in comparison to IPv4 due to the bigger
overhead constraints of IPv6.
It is an overall observation that router-to-router RTT (latency) performance figures

are always less than those of the host-to-host values.
7.2
SCOPE FOR FUTURE WORKS
Our experiment was confined within a prototype kind of experimental setup

comprising of two PCs and two IPv6 enabled routers connected through UTP Ethernet
cross cables. We found more or less acceptable results in all the experiments carried
out so far. But to be more realistic, more experiments are to be carried out in a bigger
network domain to get the actual values for the performance parameters.
Also, we were confined within bandwidth utilization and RTT (latency) parameters
measurements in our experiments only.
More research on the following aspects will be useful for further study in this area:
1. Study can be extended to comparative evaluation with IPv6 implementation on
other platforms, such as Sun Solaris 10 operating platform;
2. Study can be extended to different router platforms, such as Nortel, Juniper
etc.
3. Study can also be extended to using IPSec in IPv6 implementation to observe
the overhead enhancement due to encryption and decryption processes;
4. Quality of Service (QoS) testing in IPv6 implementation;
5. Study can be extended to application test in IPv6-enabled applications
services, such as email, web, ftp, video conferencing etc.
73
REFERENCES
[1]
Postal, J. Internet Protocol. RFC 791, September 1981
[2]
The Internet Engineering Task Force (IETF) http:// www.ietf.org.
[3]
Deering, S., and Hinder, Internet Protocol, Version 6 (IPv6) Specification.

RFC 2460, December 1998
[4]
The Design and Implementation of an IPv6/IPv4 Network Address and

Protocol Translator Department of Computer Science and Engineering,
University of Washington, Seattle, Washington 98195
http://www.cs.princeton.edu/~mef/research/napt/reports/usenix98/
[5]
Ioan Raicu IPv6 Performance Results, cs.wayne.edu
[6]
Yi Wang 1, Shaozhi Ye 2, Xing Li, Understanding Current IPv6

Performance: A Measurement Study, 3 Department of Electronic
Engineering, Tsinghua University, Beijing 100084, P. R. China
http://doi.ieeecomputersociety.org/10.1109/ISCC.2005.151
[7]
Sharif Ghazzawi and Chongenun Lee, Application Response Times for

Internet Protocol Version 4 (IPv4) versus Internet Protocol Version 6 (IPv6),
The MITRE Corporation, 7525 Colshire Dr. McLean, VA 22102
http://www.mitre.org/work/tech_papers/tech_papers_05/05_0231/05_0231.pdf
[8]
IPv6 and the Next Generation Internet Protocol Overview, Sprint

Communications, Inc., 26750 Agoura Road ,Calabasas, CA, 91302 USA
http://www.spirentcom.com/documents/3191.pdf
[9]
Peter Ping Xie, Network Protocol Performance Evaluation of IPv6 for

Windows NT, California Polytechnic State University, June 1999
[10]
Ioan Raicu An Empirical Analysis Of Internet Protocol Version 6 (IPv6) ,

Wayne State University, Detroit, Michigan, year 2002
[11]
Behrouz A. Forouzan, Business Data Communications, DeAnza College

published year 2003
[12]
Introduction to IP Version 6, published by Microsoft Corporation, published

September 2003 and updated February 2006
[13]
Marcus, A. Goncalves, Kitty Niles IPv6 Networks, McGraw-Hill, 1998
[14]
R. Gillign, E. Nordmark, Transition Mechanisms for IPv6 Hosts and

Routers, RFC-2893, August 2000
[15]
IPv6 Transition Technologies, Microsoft Corporation, Published October

2003 and updated October 2005
[16]
R. Gillign, E. Nordmark, Transition Mechanisms for IPv6 Hosts and

Routers, RFC-1933, Internet Engineering Task Force, April 1996
[17]
IPerf WWW pages http://dast.nlanr.net/Projects/Iperf
[18]
Matthew Liotine, Mission-Critical Network Planning Publisher: Artech

House Publishers (October 2003)
[19]
S. Zeadally, R. Wasseem, I. Raicu Comparison of end-system IPv6 protocol

stacksIEEE Proceedings - Communication, Vol. 151, No. 3, June 2004
[20]
W. Fink, 6BONE Web Site, 2000, URL http://www.6bone.net.
[21]
The IP specification was published as RFC 791 in September 1981 and was
later ratified as Internet Standard 5
[22]
Hiden. R., and S. Deering, IP Version 6 Addressing Architecture. RFC

2373, July 1998
[23]
Rekhter, Y., and T. Li, An Architecture for IPv6 Unicast Address

Allocation. RFC 1887, December 1995
[24]
Partridge, C., T. Mendez, and W. Milliken, Host Anycasting Service. RFC

1546, November 1993
75
APPENDICES
A: HARDWARE SPECIFICATIONS
Hardware Information
Sl No
Descriptions
Workstation
Laptop
Computer
2
Router
Cabling
Processor
Speed
Motherboard
RAM
Hard Disk
Ethernet Card
Processor
Speed
Motherboard
RAM
Hard Disk
Ethernet Card
Brand/Model
Processor
RAM
Ethernet Card
Brand/Model
Category
Type
Configuration
Specifications
: Intel Pentium III
: 800 MHz
: Intel
: 256 MB
: 40 GB
: 3Com Ether-Link 10/100
: Intel Pentium III
: 550 MHz
: Intel
: 128 MB
: 40 GB
: Intel (R) PRO/100MiniPCI
: CISCO 2811XM
: 433 MHz
: 256 MB
: TWO 10/100
: D-link
: CAT 5 copper
: UTP
: Cross cabling
Quantity
2
2
3
B: SOFTWARE SPECIFICATIONS
Software Information
Sl No
Operating System
Quantity
Windows 2003 Standard server with service pack 1
Red Hat Linux Enterprise Version 4
C: THEORETICAL IP PACKET OVERHEAD

An IP packet breakdown and overhead incurred by
the header information as below:
Descriptions\Protocols
IPv6
(TCP)
IPv4
(UDP)
IPv6
(UDP)
1460
1440
1472
1452
20
20
1480
1460
1480
1460
IP Header (NLH)
20
40
20
40
Ethernet Header (DLLH)
14
14
14
14
Total Ethernet MTU
1514
1514
1514
1514
Overhead in %
3.7%
Payload (Data)
IPv4
(TCP)
TCP\UDP Header (TLH)

IP Payload
Differences
5.14% 2.85% 4.27%
1.44%
1.42%
MTU=Payload+TLH+NLH+DLLH
Notes: MTU = Maximum Transfer Unit
Payload = Data
TLH = Transport Layer Header
NLH = Network Layer Header
DLLH = Data Link Layer Header
77
D: TESTING TOOLS SPECIFICATIONS

Tools Information
Sl
No
1
Tools Name
IPerf 1.7.0
Description
Quantity
IPerf is a ttcp like tool with considerable

advantages over it. Using a client-server model
to determine maximum bandwidth you can also

measure
delay
jitter,
packet
loss,
determineMTU, support TCP windowsize, run

tests by amount transferred or for a specified
period of time. Server can handle multiple
simul- taneous connections. Client can create
UDP streams of specified bandwidth. Clientserver model can use for testing bidirectional
mode called .dual testing mode.. IPerf uses
representative streams to test out how link layer
compression affects your achievable bandwidth
and prints periodic intermediate bandwidth,
jitter, and loss reports at specified intervals. As
one of the few also supports IPv6.
PING
Native
78
E: IPv6 CONFIGURATION IN DIFFERENT PLATFORMS

E1. IPv6 Configuration in Cisco Router
Following accessories and knowledge would be required to configure a router:
1. Router
2. a console cable
3. a terminal emulation program which came with Windows as built-in tools
4. a pc or laptop should have a COM port
5. knowledge about NVRAM, RAM, ROM, Flash, TFTP and Cisco IOS
(Internetworking Operating System)
IPv4 configuration is easier and its materials are available, so our concentration would
be in IPv6 configuration under Cisco 2811 router.
Implementing basic IPv6 connectivity in the Cisco IOS software consists of assigning
IPv6 addresses to individual router interfaces. The forwarding of IPv6 traffic can be
enabled globally, and Cisco Express Forwarding (CEF) switching for IPv6 can also be
enabled.
a. Prerequisites for Implementing Basic Connectivity for IPv6:
To forward IPv6 traffic using CEFv6, you must configure forwarding of
IPv6 unicast datagrams globally on the router by using the ipv6 unicastrouting global configuration command, and you must configure an IPv6
address on an interface by using the ipv6 address interface configuration
command.
You must enable CEF for IPv4 (CEFv4) globally on the router by using
the ip cef global configuration command before enabling CEFv6 globally
on the router by using the ipv6 cef global configuration command.
Minimum Required Cisco IOS Release 12.4
79
b. Configuring IPv6 Addressing and Enabling IPv6 Routing

This task explains how to assign IPv6 addresses to individual router interfaces and
enable the forwarding of IPv6 traffic globally on the router. By default, IPv6
addresses are not configured and IPv6 routing is disabled.
Summary Steps
1. enable
2. configure terminal
3. interface type number
4. ipv6 address ipv6-prefix/prefix-length eui-64
or
ipv6 address ipv6-address link-local
or
ipv6 address ipv6-prefix/prefix-length anycast
or
ipv6 enable
5. exit
6. ipv6 unicast-routing
c. Configuring Manual Tunneling for IPv6

The following example configures a manual IPv6 tunnel between router A and router
B. In the example, tunnel interface 0 for both router A and router B is manually
configured with a global IPv6 address. The tunnel source and destination addresses
are also manually configured.
Router site1_wan0 Configuration

interface ethernet 0
ip address 192.168.20.1 255.255.255.0
interface tunnel 0
ipv6 address 11:11:11:11:11:11:11:11/127
tunnel source ethernet 0
tunnel destination 192.168.30.1
tunnel mode ipv6ip
Router site2_wan Configuration
interface ethernet 0
ip address 192.168.30.1 255.255.255.0
interface tunnel 0
ipv6 address 22:22:22:22:22:22:22:22:/127
tunnel source ethernet 0
tunnel destination 192.168.20.1
tunnel mode ipv6ip
80
E2. IPv6 configuration in Windows 2003 Server

C:\>netsh interface ipv6 add address interface=ifindex 11:11:11:11:11:11:11:11
E3. IPv6 configuration in Linux

# ip addr add 11:11:11:11:11:11:11:11/64 dev eth0
E4. Showing configured address

Linux
Win2003
Cisco
ifconfig a
ipconfig/all
show ipv6 interface
E5. Connectivity testing using ping

Linux
Win2003
Cisco
ping6 I if
ping
ping ipv6
E6. Showing Neighbor cache

Linux
Win2003
Cisco
ip f inet6 neigh
netsh interface ipv6 show neighbors
show ipv6 neighbors
E7. Showing routes

Linux
Win2003
Cisco
ip f inet6 route
netsh interface ipv6 show routes
show ipv6 route
81
F: LOGS GENERATED BY TESTING TOOLS

F.1 TCP version 4 protocol logs from Windows
Microsoft Windows [Version 5.2.3790]
(C) Copyright 1985-2003 Microsoft Corp.
C:\Documents and Settings\Administrator>cd\
C:\>cd test
C:\test>iperf.exe -c 192.168.20.11 -n 128K
-----------------------------------------------------------Client connecting to 192.168.20.11, TCP port 5001
TCP window size: 8.00 KByte (default)
-----------------------------------------------------------[1948] local 192.168.20.22 port 1207 connected with 192.168.20.11 port 5001
[ ID] Interval
Transfer Bandwidth
[1948] 0.0- 0.0 sec 128 KBytes 52.4 Mbits/sec
[ ID] Interval
Transfer Bandwidth
[ ID] Interval
Transfer Bandwidth
[ ID] Interval
Transfer Bandwidth
82

[ ID] Interval
Transfer Bandwidth
[ ID] Interval
Transfer Bandwidth
[ ID] Interval
Transfer Bandwidth
[ ID] Interval
Transfer Bandwidth
[1948] 0.0- 0.1 sec 1.00 MBytes 93.1 Mbits/sec
[ ID] Interval
Transfer Bandwidth
83
[ ID] Interval
Transfer Bandwidth
[ ID] Interval
Transfer Bandwidth
C:\test>iperf.exe -c 192.168.20.11 -n 5M
[ ID] Interval
Transfer Bandwidth
[ ID] Interval
Transfer Bandwidth
[ ID] Interval
Transfer Bandwidth
[ ID] Interval
Transfer Bandwidth
84

[ ID] Interval
Transfer Bandwidth
[ ID] Interval
Transfer Bandwidth
[ ID] Interval
Transfer Bandwidth
[ ID] Interval
Transfer Bandwidth
[ ID] Interval
Transfer Bandwidth
------------------------------------------------------------
85
[1948] local 192.168.20.22 port 1192 connected with 192.168.20.11 port 5001
[ ID] Interval
Transfer Bandwidth
[ ID] Interval
Transfer Bandwidth
[ ID] Interval
Transfer Bandwidth
C:\test>
F.2 TCP version 6 protocol logs from Windows

C:\test>iperf.exe -c 11:11:11:11:11:11:11:11 -n 128K
-----------------------------------------------------------Client connecting to 11:11:11:11:11:11:11:11, TCP port 5001
-----------------------------------------------------------[1948] local 11:11:11:11:11:11:11:22 port 1064 connected with 11:11:11:11:11:11:
11:11 port 5001
[ ID] Interval
Transfer Bandwidth
11:11 port 5001
[ ID] Interval
Transfer Bandwidth
86

11:11 port 5001
[ ID] Interval
Transfer Bandwidth
11:11 port 5001
[ ID] Interval
Transfer Bandwidth
11:11 port 5001
[ ID] Interval
Transfer Bandwidth
11:11 port 5001
[ ID] Interval
Transfer Bandwidth
11:11 port 5001
[ ID] Interval
Transfer Bandwidth
87

11:11 port 5001
[ ID] Interval
Transfer Bandwidth
11:11 port 5001
[ ID] Interval
Transfer Bandwidth
11:11 port 5001
[ ID] Interval
Transfer Bandwidth
11:11 port 5001
[ ID] Interval
Transfer Bandwidth
C:\test>iperf.exe -c 11:11:11:11:11:11:11:11 -n 5M
11:11 port 5001
[ ID] Interval
Transfer Bandwidth
88

11:11 port 5001
[ ID] Interval
Transfer Bandwidth
11:11 port 5001
[ ID] Interval
Transfer Bandwidth
11:11 port 5001
[ ID] Interval
Transfer Bandwidth
11:11 port 5001
[ ID] Interval
Transfer Bandwidth
11:11 port 5001
[ ID] Interval
Transfer Bandwidth
89

11:11 port 5001
[ ID] Interval
Transfer Bandwidth
11:11 port 5001
[ ID] Interval
Transfer Bandwidth
11:11 port 5001
[ ID] Interval
Transfer Bandwidth
11:11 port 5001
[ ID] Interval
Transfer Bandwidth
11:11 port 5001
[ ID] Interval
Transfer Bandwidth
90

11:11 port 5001
[ ID] Interval
Transfer Bandwidth
C:\test>
F.3 UDP version 4 protocol logs from Windows

C:\>cd test
C:\test>iperf.exe -s -u
-----------------------------------------------------------Server listening on UDP port 5001
Receiving 1470 byte datagrams
UDP buffer size: 8.00 KByte (default)
[ ID] Interval
Transfer Bandwidth
Jitter Lost/Total Datagrams
[1964] 0.0- 0.0 sec 129 KBytes 35.2 Mbits/sec 0.464 ms 0/ 90 (0%)
[ ID] Interval
Transfer Bandwidth
[ ID] Interval
Transfer Bandwidth
[ ID] Interval
Transfer Bandwidth
[ ID] Interval
Transfer Bandwidth
[ ID] Interval
Transfer Bandwidth
[ ID] Interval
Transfer Bandwidth
[ ID] Interval
Transfer Bandwidth
[ ID] Interval
Transfer Bandwidth
91
[ ID] Interval
Transfer Bandwidth
[ ID] Interval
Transfer Bandwidth
[1964] 0.0- 0.1 sec 629 KBytes 51.4 Mbits/sec 0.235 ms 8/ 446 (1.8%)
[ ID] Interval
Transfer Bandwidth
[ ID] Interval
Transfer Bandwidth
[ ID] Interval
Transfer Bandwidth
[ ID] Interval
Transfer Bandwidth
[1964] 0.0- 0.1 sec 1.00 MBytes 64.5 Mbits/sec 0.142 ms 0/ 714 (0%)
[ ID] Interval
Transfer Bandwidth
[ ID] Interval
Transfer Bandwidth
[ ID] Interval
Transfer Bandwidth
[ ID] Interval
Transfer Bandwidth
[1964] 0.0- 0.1 sec 1.11 MBytes 71.6 Mbits/sec 0.184 ms 10/ 803 (1.2%)
[ ID] Interval
Transfer Bandwidth
[ ID] Interval
Transfer Bandwidth
[ ID] Interval
Transfer Bandwidth
[ ID] Interval
Transfer Bandwidth
[ ID] Interval
Transfer Bandwidth
[ ID] Interval
Transfer Bandwidth
[ ID] Interval
Transfer Bandwidth
92
[ ID] Interval
Transfer Bandwidth
[ ID] Interval
Transfer Bandwidth
[ ID] Interval
Transfer Bandwidth
F.4 UDP version 6 protocol logs from Windows

C:\>cd test
C:\test>iperf.exe -s -u -V
-----------------------------------------------------------Server listening on UDP port 5001
Receiving 1470 byte datagrams
UDP buffer size: 8.00 KByte (default)
-----------------------------------------------------------[1964] local :: port 5001 connected with 11:11:11:11:11:11:11:22 port 1149
[ ID] Interval
Transfer Bandwidth
[1964] local :: port 5001 connected with 11:11:11:11:11:11:11:22 port 1150
[ ID] Interval
Transfer Bandwidth
[ ID] Interval
Transfer Bandwidth
[ ID] Interval
Transfer Bandwidth
[ ID] Interval
Transfer Bandwidth
[ ID] Interval
Transfer Bandwidth
[ ID] Interval
Transfer Bandwidth
[ ID] Interval
Transfer Bandwidth
[ ID] Interval
Transfer Bandwidth
93
[ ID] Interval
Transfer Bandwidth
[ ID] Interval
Transfer Bandwidth
[ ID] Interval
Transfer Bandwidth
[ ID] Interval
Transfer Bandwidth
[ ID] Interval
Transfer Bandwidth
[ ID] Interval
Transfer Bandwidth
[ ID] Interval
Transfer Bandwidth
[ ID] Interval
Transfer Bandwidth
[ ID] Interval
Transfer Bandwidth
[ ID] Interval
Transfer Bandwidth
[ ID] Interval
Transfer Bandwidth
[ ID] Interval
Transfer Bandwidth
[ ID] Interval
Transfer Bandwidth
[ ID] Interval
Transfer Bandwidth
[ ID] Interval
Transfer Bandwidth
[ ID] Interval
Transfer Bandwidth
94
[ ID] Interval
Transfer Bandwidth
[ ID] Interval
Transfer Bandwidth
[ ID] Interval
Transfer Bandwidth
[ ID] Interval
Transfer Bandwidth
[ ID] Interval
Transfer Bandwidth
[ ID] Interval
Transfer Bandwidth
[ ID] Interval
Transfer Bandwidth
[ ID] Interval
Transfer Bandwidth
[ ID] Interval
Transfer Bandwidth
F.5 TCP version 4 protocol logs from Linux

TCP window size: 16.0 KByte (WARNING: requested 8.00 KByte)
-----------------------------------------------------------[ 3] local 192.168.20.22 port 32791 connected with 192.168.20.11 port 5001
[ 3] 0.0- 0.0 sec 128 KBytes 98.1 Mbits/sec
95
[ 3] 0.0- 0.1 sec 1.00 MBytes 94.7 Mbits/sec
96

------------------------------------------------------------
97
Client connecting to 192.168.20.11, TCP port 5001

F.6 TCP version 6 protocol logs from Linux

-----------------------------------------------------------[ 3] local 11:11:11:11:11:11:11:22 port 32920 connected with
11:11:11:11:11:11:11:11 port 5001
11:11:11:11:11:11:11:11 port 5001
11:11:11:11:11:11:11:11 port 5001
11:11:11:11:11:11:11:11 port 5001
----------------------------------------------------------98
Client connecting to 11:11:11:11:11:11:11:11, TCP port 5001

11:11:11:11:11:11:11:11 port 5001
11:11:11:11:11:11:11:11 port 5001
11:11:11:11:11:11:11:11 port 5001
11:11:11:11:11:11:11:11 port 5001
11:11:11:11:11:11:11:11 port 5001
11:11:11:11:11:11:11:11 port 5001
11:11:11:11:11:11:11:11 port 5001
99

11:11:11:11:11:11:11:11 port 5001
11:11:11:11:11:11:11:11 port 5001
11:11:11:11:11:11:11:11 port 5001
11:11:11:11:11:11:11:11 port 5001
11:11:11:11:11:11:11:11 port 5001
11:11:11:11:11:11:11:11 port 5001
11:11:11:11:11:11:11:11 port 5001
100

11:11:11:11:11:11:11:11 port 5001
11:11:11:11:11:11:11:11 port 5001
11:11:11:11:11:11:11:11 port 5001
11:11:11:11:11:11:11:11 port 5001
11:11:11:11:11:11:11:11 port 5001
11:11:11:11:11:11:11:11 port 5001
11:11:11:11:11:11:11:11 port 5001
------------------------------------------------------------
101
[ 3] local 11:11:11:11:11:11:11:22 port 32978 connected with

11:11:11:11:11:11:11:11 port 5001
11:11:11:11:11:11:11:11 port 5001
11:11:11:11:11:11:11:11 port 5001
11:11:11:11:11:11:11:11 port 5001
11:11:11:11:11:11:11:11 port 5001
11:11:11:11:11:11:11:11 port 5001
11:11:11:11:11:11:11:11 port 5001
------------------------------------------------------------
102

11:11:11:11:11:11:11:11 port 5001
11:11:11:11:11:11:11:11 port 5001
11:11:11:11:11:11:11:11 port 5001
11:11:11:11:11:11:11:11 port 5001
11:11:11:11:11:11:11:11 port 5001
11:11:11:11:11:11:11:11 port 5001
11:11:11:11:11:11:11:11 port 5001
------------------------------------------------------------
103

11:11:11:11:11:11:11:11 port 5001
11:11:11:11:11:11:11:11 port 5001
11:11:11:11:11:11:11:11 port 5001
11:11:11:11:11:11:11:11 port 5001
11:11:11:11:11:11:11:11 port 5001
11:11:11:11:11:11:11:11 port 5001
11:11:11:11:11:11:11:11 port 5001
------------------------------------------------------------
104

11:11:11:11:11:11:11:11 port 5001
11:11:11:11:11:11:11:11 port 5001
[ 3] 0.0-2.7 sec 30.0 MBytes 92.6 Mbits/sec
11:11:11:11:11:11:11:11 port 5001
11:11:11:11:11:11:11:11 port 5001
11:11:11:11:11:11:11:11 port 5001
11:11:11:11:11:11:11:11 port 5001
11:11:11:11:11:11:11:11 port 5001
------------------------------------------------------------
105

11:11:11:11:11:11:11:11 port 5001
11:11:11:11:11:11:11:11 port 5001
11:11:11:11:11:11:11:11 port 5001
11:11:11:11:11:11:11:11 port 5001
11:11:11:11:11:11:11:11 port 5001
11:11:11:11:11:11:11:11 port 5001
-----------------------------------------------------------[ 3] local :: port 0 connected with 11:11:11:11:11:11:11:11 port 5001
[ 3] 0.0- 0.0 sec 0.00 Bytes 0.00 bits/sec
-----------------------------------------------------------[ 3] local :: port 0 connected with 11:11:11:11:11:11:11:11 port 5001
[ 3] 0.0- 0.0 sec 0.00 Bytes 0.00 bits/sec
106

11:11:11:11:11:11:11:11 port 5001
11:11:11:11:11:11:11:11 port 5001
11:11:11:11:11:11:11:11 port 5001
11:11:11:11:11:11:11:11 port 5001
F7. Latency RTT in Linux

PING 11:11:11:11:11:11:11:11(11:11:11:11:11:11:11:11) 5000 data bytes
5008 bytes from 11:11:11:11:11:11:11:11: icmp_seq=0 ttl=64 time=1.08 ms
--- 11:11:11:11:11:11:11:11 ping statistics --10 packets transmitted, 10 received, 0% packet loss, time 9007ms
rtt min/avg/max/mdev = 1.017/1.040/1.086/0.044 ms, pipe 2
PING 11:11:11:11:11:11:11:11(11:11:11:11:11:11:11:11) 10000 data bytes
107

PING 11:11:11:11:11:11:11:11(11:11:11:11:11:11:11:11) 15000 data bytes
PING 11:11:11:11:11:11:11:11(11:11:11:11:11:11:11:11) 10000 data bytes
PING 11:11:11:11:11:11:11:11(11:11:11:11:11:11:11:11) 20000 data bytes
PING 11:11:11:11:11:11:11:11(11:11:11:11:11:11:11:11) 25000 data bytes
108

PING 11:11:11:11:11:11:11:11(11:11:11:11:11:11:11:11) 30000 data bytes
PING 11:11:11:11:11:11:11:11(11:11:11:11:11:11:11:11) 35000 data bytes
PING 11:11:11:11:11:11:11:11(11:11:11:11:11:11:11:11) 40000 data bytes
109

PING 11:11:11:11:11:11:11:11(11:11:11:11:11:11:11:11) 45000 data bytes
PING 11:11:11:11:11:11:11:11(11:11:11:11:11:11:11:11) 50000 data bytes
PING 11:11:11:11:11:11:11:11(11:11:11:11:11:11:11:11) 55000 data bytes
110
PING 11:11:11:11:11:11:11:11(11:11:11:11:11:11:11:11) 60000 data bytes
111
G: PHOTO SESSION ON LABORATORY SETUP FOR THE EXPERIMENT

1. Researcher is standing behind the full lab set up
2. Researcher is trying to plug in UTP cable to routers
3. Researcher is trying to plug in cables to routers
112
4. Researching is trying to configure routers suing hyper terminal tool
5. Researcher is trying to test the connectivity among the routers
6. Researcher is trying to test the connectivity among the machines
113
7. Researcher is starting test
8. Researcher is observing test results
9. Researcher is capturing test results
114

10 1 1 133 4437 PDF

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

10 1 1 133 4437 PDF

Загружено:

Авторское право:

Доступные форматы

A COMPARATIVE STUDY ON THE PERFORMANCE OF IPv4 AND IPv6

Mohammad Mokbul Ahmed

A Thesis Presented in Partial Fulfillment

INDEPENDENT UNIVERSITY, BANGLADESH

A COMPARATIVE STUDY ON THE PERFORMANCE OF IPv4 AND IPv6

has been approved

Professor Dr. M. Lutfar Rahman,

Dr. Indrani Haque,

Dr. Feroz Ahmed,

AIMS AND OBJECTIVES OF THE STUDY . . . . . . . . . . . . ..

ORGANIZATION OF THE THESIS. . . . . .. . . .

LITERATURE REVIEW AND THEORETICAL DEVELOPMENT. . 4

2.2.1 Internet and the TCP/IP Reference Model.

2.3.1 The IPv6 Specification

2.3.2 The IPv6 Addressing Architecture.

2.3.3 IPv4 vs. IPv6..

IPv4 TO IPv6 TRANSITION MECHANISMS AND

2.4.1 Dual IP Layer.

2.4.2 IPv6 Over IPv4 Tunneling.

REVIEWING THE BASIC FUNCTIONALITIES AND

LABORATORY SETUP FOR THE EXPERIMENT . . .

IPv4 AND IPv6 PERFORMANCE ANALYSIS . . . . . . . . . . . . .

4.1.1 Bandwidth Utilization

4.1.2 Round Trip Time .... 45

POINT-TO-POINT TEST-LAB PERFORMANCE.. 46

4.2.2 Round Trip Time 51

ROUTER-TO-ROUTER TEST-LAB PERFORMANCE.. 53

4.3.2 Round Trip Time 57

IPv4 TO IPv6 MIGRATION MECHANISMS AND

HOST-TO-HOST AND ROUTER-TO-ROUTER

5.1.2 Round Trip Time 63

RESULTS AND DISCUSSIONS. . . . . . . . . . . .

RESULTS AND DISCUSSIONS..

6.2.1 Bandwidth Utilization for Point-to-Point

6.2.2 Round Trip Time Computation

6.2.3 Bandwidth Utilization

6.2.4 Round Trip Time Computation

6.2.5 Bandwidth Utilization for Host-to-Host

6.2.6 Round Trip Time Computation for Host-to-Host

CONCLUSION AND SCOPE FOR FUTURE WORKS. . ..

7.2 SCOPE FOR FUTURE WORKS . 73

THEORETICAL IP PACKET OVERHEAD.. 77

TESTING TOOLS SPECIFICATIONS.

IPv6 CONFIGURATIONS IN DIFFERENT PLATFORMS

LOGS GENERATED BY TESTING TOOLS 82

2.1 Values of the Next Header Field of IPv6..

2.2 Differences between IPv4 and IPv6... 31

2.1 Internet Model...

2.2 The IPv4 Header...

2.3 The IPv6 Header 13

2.6 The link-local address 21

2.8 The local address 22

2.12 The conversion of an IEEE 802 address to an EUI-64 address

2.13 The conversion of a universally administered, unicast

2.14 The conversion of a universally administered, unicast

2.15 A Dual IP Layer Architecture...

2.16 IPv6 over IPv4 Tunneling....

2.17 Router-to-Router Tunneling..

2.18 Host-to-Router and Router-to-Host Tunneling.

2.19 Host-to-Host Tunneling....

4.1 Point-to-Point Test-Labs Architecture; two computers are directly

4.4 Bandwidth Utilization Results for IPv4/IPv6 under Linux

4.5 Bandwidth Utilization Results for IPv4/IPv6 under Linux