10.1.1.133.4437.pdf
-
Upload
sagar-mohite -
Category
Documents
-
view
218 -
download
0
description
Transcript of 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)
iii
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.
iv
We also find that router-to-router tunneling performs always better than the host-to-
host 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.
v
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 whole-
hearted 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.
vi
TABLE OF CONTENTS
Page
LIST OF TABLES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ix
LIST OF FIGURES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . x
CHAPTER
1 INTRODUCTION . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.1 INTRODUCTION . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . … 1
1.2 AIMS AND OBJECTIVES OF THE STUDY . . . . . . . . . . . . .. 2
1.3 ORGANIZATION OF THE THESIS. . . . . .. ………… . . . … 3
2 LITERATURE REVIEW AND THEORETICAL DEVELOPMENT. . 4
2.1 LITERATURE REVIEW……… . . . . . . . . . . . . . . . . …. . . . . 4
2.2 A LAYERING APPROACH…………………………………. 8
2.2.1 Internet and the TCP/IP Reference Model……………. 9
2.3 IPv6 ACCOMPLISHMENT……..…………………………… 9
2.3.1 The IPv6 Specification………………………………… 9
2.3.2 The IPv6 Addressing Architecture……………………. 15
2.3.3 IPv4 vs. IPv6………………………………………….. 31
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
3 METHODOLOGY . . . . . . . . . . . . . . . . . . . . . . . . ……. . . . . . . . … 41
3.1 REVIEWING THE BASIC FUNCTIONALITIES AND
PERFORMANCE OF IPv4 AND IPv6……………................. 41
vii
CHAPTER Page
3.2 STUDYING LAYERING APPROACHES AND ARCHITECTURES
OF IPv4 AND IPv6…………………………………………… 41
3.3 LABORATORY SETUP FOR THE EXPERIMENT .… . . … 41
3.4 EXPERIMENTAL . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . ….. 42
4 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
4.2.1 Bandwidth Utilization………………………………… 46
4.2.2 Round Trip Time ……………………………………… 51
4.3 ROUTER-TO-ROUTER TEST-LAB PERFORMANCE…….. 53
4.3.1 Bandwidth Utilization………………………………… 54
4.3.2 Round Trip Time ……………………………………… 57
4.4 CONCLUSION………….……………………………………. 58
5 IPv4 TO IPv6 MIGRATION MECHANISMS AND
PERFORMANCE ANALYSIS…………………………….…......... 59
5.1 HOST-TO-HOST AND ROUTER-TO-ROUTER
TUNNELING PERFORMANCE ……………………..……… 59
5.1.1 Bandwidth Utilization…………………………............ 60
5.1.2 Round Trip Time ……………………………………… 63
5.2 CONCLUSION………….…………………………………… 64
viii
CHAPTER Page
6 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
6.2.3 Bandwidth Utilization
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
B SOFTWARE SPECIFICATIONS…………… . . . . . . . . . . . ……… 76
C THEORETICAL IP PACKET OVERHEAD……………………….. 77
D TESTING TOOLS SPECIFICATIONS…………….……………… 78
E IPv6 CONFIGURATIONS IN DIFFERENT PLATFORMS……… 79
F LOGS GENERATED BY TESTING TOOLS……………………… 82
ix
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…………………………………. 33
x
LIST OF FIGURES
Figure Page
2.1 Internet Model…………………………………………………………... 9
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
xi
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
4.3 Bandwidth Utilization Results for IPv4/IPv6 under Windows
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
4.5 Bandwidth Utilization Results for IPv4/IPv6 under Linux
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
4.7 Bandwidth Utilization Results for IPv6 under Linux and
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
4.9 Bandwidth Utilization Results for IPv6 under Linux and
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
4.11 Bandwidth Utilization Results for IPv4/IPv6 under Windows
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…………………………………………. 51
xii
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
4.16 Bandwidth Utilization Results for IPv4/IPv6 under Windows
with data size ranging from 128 KB to 1.408 MB……………………. 54
4.17 Bandwidth Utilization Results for IPv4/IPv6 under Windows
with data size ranging from 5.12 to 61.44 MB……………………….… 54
4.18 Bandwidth Utilization Results for IPv4/IPv6 under Linux
with data size ranging from 128KB to 1.408 MB……..…………… 55
4.19 Bandwidth Utilization Results for IPv4/IPv6 under Linux
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
4.21 Bandwidth Utilization Results for IPv4/IPv6 under Windows
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
xiii
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, Router-
to-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, Router-
to-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-to-
Router 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
xiv
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
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.4×238
addresses), we can connect more devices to the Internet without breaking the end-to-
end 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).
2
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.
3
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
5
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 NT’s 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 today’s 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
6
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
7
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.
8
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.
9
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 model’s 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.
10
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
11
0’s, 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 (15×4).
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 flags—one 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
12
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.
13
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
14
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
15
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 6 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 protocol’s 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
16
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.4×1038) 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.5×1023) addresses for every square meter of the
Earth’s 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.5×1023 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
17
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
18
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-to-
many 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.
19
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
20
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
organization’s site. The interface identifier identifies a specific interface on a subnet
within an organization’s site. For more information about global unicast addresses,
see RFC 3587.
21
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.
22
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.
23
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.
24
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 low-
order 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.
25
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
addresses—even 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 packets—a 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
26
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 64-
bit 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.
27
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).
28
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
29
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
30
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:
31
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 IPv4’s features and the right side represents IPv6’s 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 QoS handling by routers is present within the IPv4 header.
Packet flow identification for QoS handling by routers is included in the IPv6 header using the Flow 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.
32
Table 2.2 Contd.
Internet Group Management Protocol (IGMP) is used to manage local subnet group membership.
IGMP is replaced with Multicast Listener Discovery (MLD) messages.
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)
33
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: IN-ADDR.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.
34
Table 2.4 Contd.
Protocol Replaced by the IPv6 Next Header field.
Header Checksum Removed in IPv6. In IPv6, bit-level 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.
35
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.
36
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 Don’t 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
37
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 organization’s 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
38
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 organization’s IPv4 infrastructure to
reach the IPv6 Internet.
39
• 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 organization’s
IPv4 infrastructure
• IPv6/IPv4 hosts that use IPv4-compatible addresses to tunnel across an
40
organization’s 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.
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
42
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 router-
to-router architecture for the computation of BW utilization and round trip time
43
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.
CHAPTER 4
IPv4 AND IPv6 PERFORMANCE ANALYSIS
In chapter 4, we explain two most key performance metrics. Then we present our test-
lab 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.
45
4.1.1 Bandwidth Utilization 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.
dKQLL
i
iq
−= ∑
=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.
46
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
4.2.1 Bandwidth Utilization
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.
Performance of TCP in IPv4 and IPv6 under Windows
0102030405060708090
100
128 256 384 512 640 768 896 1024 1152 1280 1408
Packet Size (KB)
Ban
dwid
th U
tiliz
atio
n (M
bits
/s)
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
47
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.
Performance of TCP in IPv4 and IPv6 under Windows
89909192939495
5120 10240 15360 20480 25600 30720 35840 40960 46080 51200 56320 61440
Packet Size (KB)
Ban
dwid
th U
tiliz
atio
n (M
bits
/s)
TCP/IPv4 W2K3 TCP/IPv6 W2K3
Figure 4.3 Bandwidth Utilization Results for IPv4/IPv6 under Windows; data sizes 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.
Performance of TCP in IPV4 and IPv6 under Linux
90
92
94
96
98
100
128 256 384 512 640 768 896 1024 1152 1280 1408
Packet Size (KB)
Ban
dwid
th U
tiliz
atio
n (M
bits
/s)
TCP/IPv4 Linux TCP/IPv6 Linux
Figure 4.4 Bandwidth Utilization Results for IPv4/IPv6 under Linux; data sizes ranging from 128KB to 1.408MB
48
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.
Performance of TCP in IPv4 and IPv6 under Linux
91
92
93
94
95
96
5120 10240 15360 20480 25600 30720 35840 40960 46080 51200 56320 61440
Packet Size (KB)
Ban
dwid
th U
tiliz
atio
n (M
bits
/s)
TCP/IPv4 Linux TCP/IPv6 Linux
Figure 4.5 Bandwidth Utilization Results for IPv4/IPv6 under Linux; data sizes 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.
Performance of TCP in IPv4 under Windows and Linux
0102030405060708090
100
128 256 384 512 640 768 896 1024 1152 1280 1408
Packet Size (KB)
Ban
dwid
th U
tiliz
atio
n (M
bits
/s)
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
49
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.
Performance of TCP in IPv6 under Windows and Linux
0102030405060708090
100
128 256 384 512 640 768 896 1024 1152 1280 1408
Packet Size (KB)
Ban
dwid
th U
tiliz
atio
n (M
bits
/s)
TCP/IPv6 W2K3 TCP/IPv6 Linux
Figure 4.7 Bandwidth Utilization Results for IPv6 under Linux and Windows; data 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.
Performance of TCP in IPv4 under Windows and Linux
9292.5
9393.5
9494.5
9595.5
5120 10240 15360 20480 25600 30720 35840 40960 46080 51200 56320 61440
Packet Size (KB)
Ban
dwid
th U
tiliz
atio
n (M
bits
/s)
TCP/IPv4 W2K3 TCP/IPv4 Linux
Figure 4.8 Bandwidth Utilization Results for IPv4 under Linux and Windows; data sizes ranging from 5.12 to 61.144 MB
50
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.
Performance of TCP in IPv6 under Windows and Linux
89.590
90.591
91.592
92.593
93.5
5120 10240 15360 20480 25600 30720 35840 40960 46080 51200 56320 61440
Packet Size (KB)
Ban
dwid
th U
tiliz
atio
n (M
bits
/s)
TCP/IPv6 W2K3 TCP/IPv6 Linux
Figure 4.9 Bandwidth Utilization Results for IPv6 under Linux and Windows; data 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.
Performance of TCP in IPv4 and IPv6 under Windows and Linux
8990919293949596
5120 10240 15360 20480 25600 30720 35840 40960 46080 51200 56320 61440
Packet Size (KB)
Ban
dwid
th U
tiliz
atio
n (M
bits
/s)
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
51
Figure 4.11 shows that both IPv4 and IPv6 protocols under Windows perform quite
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.
Performance of UDP in IPv4 and IPV6 under Windows
0102030405060708090
100
128 256 384 512 640 768 896 1024 1152 1280 1408
Packet Sized (KB)
Ban
dwid
th U
tiliz
atio
n (M
bits
/s)
UDP/IPv4 W2K3 UDP/IPv6 W2K3
Figure 4.11 Bandwidth Utilization Results for IPv4/IPv6 under Windows; data sizes ranging from 128KB to 1.408MB 4.2.2 Round Trip Time (Latency)
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.
Performance of Latency in IPv4 and IPv6 under Windows
02468
101214
5120 10240 15360 20480 25600 30720 35840 40960 46080 51200 56320 61440
Packet Size (Bytes)
Late
ncy
- RTT
(ms)
TCP/IPv4 W2K3 TCP/IPv6 W2K3
Figure 4.12 Round Trip Time Results for IPv4/IPv6 under Windows; data sizes ranging from 5.12 to 61.44 MB
52
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.
Performance of Latency in IPv4 and IPv6 under Linux
02468
1012
5120 10240 15360 20480 25600 30720 35840 40960 46080 51200 56320 61440
Packet Size (Bytes)
Late
ncy
- RTT
(ms)
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.
Performance of Latency in IPv4 and IPv6 under Windows and Linux
02468
101214
5120 10240 15360 20480 25600 30720 35840 40960 46080 51200 56320 61440
Packet Size (bytes)
Late
ncy
- RTT
(ms)
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
53
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-to-
router 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
54
4.3.1 Bandwidth Utilization
Figure 4.16 shows that both IPv4 and IPv6 protocols under Windows perform quite
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.
Performance of TCP in IPv4 and IPv6 under Windows
0102030405060708090
100
128 256 384 512 640 768 896 1024 1152 1280 1408
Packet Size (KB)
Ban
dwid
th U
tiliz
atio
n (M
bits
/s)
TCP/IPv4 W2K3 TCP/IPv6 W2K3
Figure 4.16 Bandwidth Utilization Results for IPv4/IPv6 under Windows; data sizes ranging from 128KB to 1.408MB 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-to-
Point architecture.
Performance of TCP in IPv4 and IPv6 under Windows
0102030405060708090
100
5120 10240 15360 20480 25600 30720 35840 40960 46080 51200 56320 61440
Packet Size (KB)
Ban
dwid
th U
tiliz
atio
n (M
bits
/s)
TCP/IPv4 W2K3 TCP/IPv6 W2K3
Figure 4.17 Bandwidth Utilization Results for IPv4/IPv6 under Windows; data sizes ranging from 5.12 to 61.44MB
55
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 Point-
to-Point architecture.
Performance of TCP in IPv4 and IPv6 under Linux
65
70
75
80
85
90
128 256 384 512 640 768 896 1024 1152 1280 1408
Packet Size (KB)
Ban
dwid
th U
tiliz
atio
n (M
bits
/s)
TCP/IPv4 Linux TCP/IPv6 Linux
Figure 4.18 Bandwidth Utilization Results for IPv4/IPv6 under Linux; data sizes ranging from 128KB to 1.408MB 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.
Performance of TCP in IPv4 and IPv6 under Linux
65
70
75
80
85
5120 10240 15360 20480 25600 30720 35840 40960 46080 51200 56320 61440
Packet Size (KB)
Ban
dwid
th U
tiliz
atio
n (M
bits
/s)
TCP/IPv4 Linux TCP/IPv6 Linux
Figure 4.19 Bandwidth Utilization Results for IPv4/IPv6 under Linux; data sizes ranging from 5.120 to 61.44MB
56
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.
Performance of TCP in IPv4/IPv6 under Windows and Linux
60
65
70
75
80
85
5120 10240 15360 20480 25600 30720 35840 40960 46080 51200 56320 61440
Packet Size (KB)
Ban
dwid
th U
tiliz
atio
n (M
bits
/s)
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 doesn’t acknowledge. It was 1 to 2% in Fig. 4.11
Point-to-Point architecture.
Performance of UDP in IPv4/IPv6 under Windows
010203040506070
128 256 384 512 640 768 896 1024 1152 1280 1408
Packet Size (KB)
Ban
dwid
th U
tiliz
atio
n (M
bits
/s)
UDP/IPv4 W2K3 UDP/IPv6 W2K3
Figure 4.21 Bandwidth Utilization Results for IPv4/IPv6 under Windows; data sizes ranging from 128KB to 1.408MB
57
4.3.2 Round Trip Time (Latency)
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.
Performance of Latency in IPv4/IPv6 under Windows
02468
101214
5120 10240 15360 20480 25600 30720 35840 40960 46080 51200 56320 61440
Packet Size (KB)
Late
ncy
- R
TT (m
s)
TCP/IPv4 W2K3 TCP/IPv6 W2K3
Figure 4.22 Round Trip Time Results for IPv4/IPv6 under Windows; data sizes ranging from 5.12 to 61.44 MB 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.
Performance of Latency IPv4/IPv6 under Linux
02468
101214
5120 10240 15360 20480 25600 30720 35840 40960 46080 51200 56320 61440
Packet Size (KB)
Late
ncy
- RTT
(ms)
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
58
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.
Performance of Latency in IPv4/IPv6 under Windows and Linux
02468
101214
5120 10240 15360 20480 25600 30720 35840 40960 46080 51200 56320 61440
Packet Size (KB)
Late
ncy
- RTT
(ms)
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 sizes ranging from 5.12 to 61.44MB 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].
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
60
Figure 5.2 shows the architecture of router-to-router Tunneling under Cisco platform.
In router-to-router tunneling, encapsulation occurs at the sender’s router end and de-
capsulation occurs at the recipient’s 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 5.1.1 Bandwidth Utilization Figure 5.3 shows that IPv6 encapsulated in IPv4, designated as IPv4 (IPv6) router-to-
router Tunneling performs better than the host-to-host Tunneling. IPv4 (IPv6) Host-
to-Host Tunneling incurs 16% more overhead.
Performance of TCP in IPv4(IPv6) Tunneling under Windows
0102030405060708090
100
5120 10240 15360 20480 25600 30720 35840 40960 46080 51200 56320 61440
Packet Size (KB)
Ban
dwid
th U
tiliz
atio
n (M
bits
/s)
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-to-Router Tunneling under Windows and Cisco; data sizes ranging from 5.12 to 61.44MB
61
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) host-
to-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.
Performance of TCP in IPv4(IPv6) Tunneling under Windows
0102030405060708090
100
5120 10240 15360 20480 25600 30720 35840 40960 46080 51200 56320 61440
Packet Size (KB)
Ban
dwid
th U
tiliz
atio
n (M
bits
/s)
TCP/IPv4(IPv6) W2K3 Host-2-Host Tunnel TCP/IPv4(IPv6) W2K3 Router-2-Router Tunnel 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 sizes ranging from 5.12 to 61.44MB 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%.
Performance of TCP in IPv4(IPv6) Tunneling under Linux
0102030405060708090
100
5120 10240 15360 20480 25600 30720 35840 40960 46080 51200 56320 61440
Packet Size (KB)
Ban
dwid
th
Util
izat
ion
(Mbi
ts/s
)
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-to-router Tunneling under Linux and Cisco; data sizes ranging from 5.12 to 61.44MB
62
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.
Performance of TCP in IPv4(IPv6) Tunneling under Linux
0102030405060708090
100
5120 10240 15360 20480 25600 30720 35840 40960 46080 51200 56320 61440
Packet Size (KB)
Ban
dwid
th U
tiliz
atio
n (M
bits
/s)
TCP/IPv4(IPv6) Linux Host-2-Host Tunnel TCP/IPv4(IPv6) Linux Router-2-Router Tunnel
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 ranging from 5.12 to 61.44MB 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.
Performance of TCP in IPv4(IPv6) Tunneling under Windows and Linux
0102030405060708090
100
5120 10240 15360 20480 25600 30720 35840 40960 46080 51200 56320 61440
Packet Size (KB)
Ban
dwid
th U
tiliz
atio
n (M
bits
/s)
TCP/IPv6 W2K3 Router-2-Router TCP/IPv4(IPv6) W2K3 Host-2-Host Tunnel
TCP/IPv4(IPv6) W2K3 Router-2-Router Tunnel TCP/IPv6 Linux Router-2-Router
TCP/IPv4(IPv6) Linux Host-2-Host Tunnel TCP/IPv4(IPv6) Linux Router-2-Router Tunnel
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; data sizes ranging from 5.12 to 61.44MB
63
5.1.2 Round Trip Time (Latency)
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.
Performance of Latency in IPv4(IPv6) Tunneling under Windows
05
1015202530
5120 10240 15360 20480 25600 30720 35840 40960 46080 51200 56320 61440
Packet Size (KB)
Late
ncy
- RTT
(ms)
TCP/IPv4(IPv6) W2K3 Host-2-Host Tunnel TCP/IPv4(IPv6) W2K3 Router-2-Router Tunnel
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.
Performance of Latency in IPv4 (IPv6) Tunneling under Linux
0
5
10
15
20
25
5120 10240 15360 20480 25600 30720 35840 40960 46080 51200 56320 61440
Packet Size (KB)
Late
ncy
- RTT
(ms)
TCP/IPv4(IPv6) Linux Host-2-Host Tunnel TCP/IPv4(IPv6) Linux Router-2-Router Tunnel
Figure 5.9 Round trip Time Results for IPv4 (IPv6) Tunneling under Linux and Cisco; data sizes ranging from 5.12 to 61.44MB
64
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].
Performance of Latency in IPv4(IPv6) Tunneling under Linux and Windows
0102030
5120 10240 15360 20480 25600 30720 35840 40960 46080 51200 56320 61440
Packet Size (KB)
Late
ncy
- RTT
(m
s)
TCP/IPv4(IPv6) Linux Host-2-Host Tunnel TCP/IPv4(IPv6) Linux Router-2-Router Tunnel
TCP/IPv4(IPv6) W2K3 Host-2-Host Tunnel TCP/IPv4(IPv6) W2K3 Router-2-Router Tunnel
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.
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-to-
router 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.
66
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
67
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
68
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.
69
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-to-
router 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.
70
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, host-
to-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.
71
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 router-
to-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 router-
to-router tunneling.
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
73
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.
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
75
[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
stacks”IEEE 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
APPENDICES
A: HARDWARE SPECIFICATIONS
Hardware Information
Sl No Descriptions Specifications Quantity 1
Workstation
Processor : Intel Pentium III Speed : 800 MHz Motherboard : Intel RAM : 256 MB Hard Disk : 40 GB Ethernet Card : 3Com Ether-Link 10/100
2
2
Laptop
Computer
Processor : Intel Pentium III Speed : 550 MHz Motherboard : Intel RAM : 128 MB Hard Disk : 40 GB Ethernet Card : Intel (R) PRO/100MiniPCI
1
3
Router
Brand/Model : CISCO 2811XM Processor : 433 MHz RAM : 256 MB Ethernet Card : TWO 10/100
2
4
Cabling
Brand/Model : D-link Category : CAT 5 copper Type : UTP Configuration : Cross cabling
3
B: SOFTWARE SPECIFICATIONS
Software Information
Sl No Operating System Quantity 1
Windows 2003 Standard server with service pack 1
2
2
Red Hat Linux Enterprise Version 4
2
77
C: THEORETICAL IP PACKET OVERHEAD
An IP packet breakdown and overhead incurred by the header information as below:
Descriptions\Protocols IPv4
(TCP) IPv6
(TCP) IPv4
(UDP) IPv6
(UDP)
Payload (Data) 1460 1440 1472 1452
TCP\UDP Header (TLH) 20 20 8 8
IP Payload 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% 5.14% 2.85% 4.27%
Differences 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
78
D: TESTING TOOLS SPECIFICATIONS
Tools Information
Sl No
Tools Name Description Quantity
1
IPerf 1.7.0
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. Client-
server 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.
1
2
PING
Native
1
79
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 unicast-
routing 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
80
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
81
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 ifconfig –a Win2003 ipconfig/all Cisco show ipv6 interface E5. Connectivity testing using ping Linux ping6 –I if Win2003 ping Cisco ping ipv6 E6. Showing Neighbor cache Linux ip –f inet6 neigh Win2003 netsh interface ipv6 show neighbors Cisco show ipv6 neighbors E7. Showing routes Linux ip –f inet6 route Win2003 netsh interface ipv6 show routes Cisco show ipv6 route
82
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 C:\test>iperf.exe -c 192.168.20.11 -n 256K ------------------------------------------------------------ Client connecting to 192.168.20.11, TCP port 5001 TCP window size: 8.00 KByte (default) ------------------------------------------------------------ [1948] local 192.168.20.22 port 1208 connected with 192.168.20.11 port 5001 [ ID] Interval Transfer Bandwidth [1948] 0.0- 0.0 sec 256 KBytes 69.8 Mbits/sec C:\test>iperf.exe -c 192.168.20.11 -n 384K ------------------------------------------------------------ Client connecting to 192.168.20.11, TCP port 5001 TCP window size: 8.00 KByte (default) ------------------------------------------------------------ [1948] local 192.168.20.22 port 1209 connected with 192.168.20.11 port 5001 [ ID] Interval Transfer Bandwidth [1948] 0.0- 0.0 sec 384 KBytes 78.5 Mbits/sec C:\test>iperf.exe -c 192.168.20.11 -n 512K ------------------------------------------------------------ Client connecting to 192.168.20.11, TCP port 5001 TCP window size: 8.00 KByte (default) ------------------------------------------------------------ [1948] local 192.168.20.22 port 1211 connected with 192.168.20.11 port 5001 [ ID] Interval Transfer Bandwidth [1948] 0.0- 0.1 sec 512 KBytes 83.8 Mbits/sec C:\test>iperf.exe -c 192.168.20.11 -n 640K
83
------------------------------------------------------------ Client connecting to 192.168.20.11, TCP port 5001 TCP window size: 8.00 KByte (default) ------------------------------------------------------------ [1948] local 192.168.20.22 port 1213 connected with 192.168.20.11 port 5001 [ ID] Interval Transfer Bandwidth [1948] 0.0- 0.1 sec 640 KBytes 87.3 Mbits/sec C:\test>iperf.exe -c 192.168.20.11 -n 768K ------------------------------------------------------------ Client connecting to 192.168.20.11, TCP port 5001 TCP window size: 8.00 KByte (default) ------------------------------------------------------------ [1948] local 192.168.20.22 port 1214 connected with 192.168.20.11 port 5001 [ ID] Interval Transfer Bandwidth [1948] 0.0- 0.1 sec 768 KBytes 89.7 Mbits/sec C:\test>iperf.exe -c 192.168.20.11 -n 896K ------------------------------------------------------------ Client connecting to 192.168.20.11, TCP port 5001 TCP window size: 8.00 KByte (default) ------------------------------------------------------------ [1948] local 192.168.20.22 port 1215 connected with 192.168.20.11 port 5001 [ ID] Interval Transfer Bandwidth [1948] 0.0- 0.1 sec 896 KBytes 91.6 Mbits/sec C:\test>iperf.exe -c 192.168.20.11 -n 1024K ------------------------------------------------------------ Client connecting to 192.168.20.11, TCP port 5001 TCP window size: 8.00 KByte (default) ------------------------------------------------------------ [1948] local 192.168.20.22 port 1216 connected with 192.168.20.11 port 5001 [ ID] Interval Transfer Bandwidth [1948] 0.0- 0.1 sec 1.00 MBytes 93.1 Mbits/sec C:\test>iperf.exe -c 192.168.20.11 -n 1152K ------------------------------------------------------------ Client connecting to 192.168.20.11, TCP port 5001 TCP window size: 8.00 KByte (default) ------------------------------------------------------------ [1948] local 192.168.20.22 port 1218 connected with 192.168.20.11 port 5001 [ ID] Interval Transfer Bandwidth [1948] 0.0- 0.1 sec 1.13 MBytes 94.2 Mbits/sec C:\test>iperf.exe -c 192.168.20.11 -n 1280K ------------------------------------------------------------ Client connecting to 192.168.20.11, TCP port 5001 TCP window size: 8.00 KByte (default) ------------------------------------------------------------ [1948] local 192.168.20.22 port 1219 connected with 192.168.20.11 port 5001
84
[ ID] Interval Transfer Bandwidth [1948] 0.0- 0.1 sec 1.25 MBytes 95.2 Mbits/sec C:\test>iperf.exe -c 192.168.20.11 -n 1408K ------------------------------------------------------------ Client connecting to 192.168.20.11, TCP port 5001 TCP window size: 8.00 KByte (default) ------------------------------------------------------------ [1948] local 192.168.20.22 port 1220 connected with 192.168.20.11 port 5001 [ ID] Interval Transfer Bandwidth [1948] 0.0- 0.1 sec 1.38 MBytes 96.0 Mbits/sec C:\test>iperf.exe -c 192.168.20.11 -n 5M ------------------------------------------------------------ Client connecting to 192.168.20.11, TCP port 5001 TCP window size: 8.00 KByte (default) ------------------------------------------------------------ [1948] local 192.168.20.22 port 1222 connected with 192.168.20.11 port 5001 [ ID] Interval Transfer Bandwidth [1948] 0.0- 0.5 sec 5.00 MBytes 93.1 Mbits/sec C:\test>iperf.exe -c 192.168.20.11 -n 10M ------------------------------------------------------------ Client connecting to 192.168.20.11, TCP port 5001 TCP window size: 8.00 KByte (default) ------------------------------------------------------------ [1948] local 192.168.20.22 port 1228 connected with 192.168.20.11 port 5001 [ ID] Interval Transfer Bandwidth [1948] 0.0- 0.9 sec 10.0 MBytes 93.3 Mbits/sec C:\test>iperf.exe -c 192.168.20.11 -n 15M ------------------------------------------------------------ Client connecting to 192.168.20.11, TCP port 5001 TCP window size: 8.00 KByte (default) ------------------------------------------------------------ [1948] local 192.168.20.22 port 1230 connected with 192.168.20.11 port 5001 [ ID] Interval Transfer Bandwidth [1948] 0.0- 1.3 sec 15.0 MBytes 93.3 Mbits/sec C:\test>iperf.exe -c 192.168.20.11 -n 20M ------------------------------------------------------------ Client connecting to 192.168.20.11, TCP port 5001 TCP window size: 8.00 KByte (default) ------------------------------------------------------------ [1948] local 192.168.20.22 port 1231 connected with 192.168.20.11 port 5001 [ ID] Interval Transfer Bandwidth [1948] 0.0- 1.8 sec 20.0 MBytes 93.5 Mbits/sec
85
C:\test>iperf.exe -c 192.168.20.11 -n 25M ------------------------------------------------------------ Client connecting to 192.168.20.11, TCP port 5001 TCP window size: 8.00 KByte (default) ------------------------------------------------------------ [1948] local 192.168.20.22 port 1166 connected with 192.168.20.11 port 5001 [ ID] Interval Transfer Bandwidth [1948] 0.0- 2.2 sec 25.0 MBytes 93.5 Mbits/sec C:\test>iperf.exe -c 192.168.20.11 -n 30M ------------------------------------------------------------ Client connecting to 192.168.20.11, TCP port 5001 TCP window size: 8.00 KByte (default) ------------------------------------------------------------ [1948] local 192.168.20.22 port 1173 connected with 192.168.20.11 port 5001 [ ID] Interval Transfer Bandwidth [1948] 0.0- 2.7 sec 30.0 MBytes 93.7 Mbits/sec C:\test>iperf.exe -c 192.168.20.11 -n 35M ------------------------------------------------------------ Client connecting to 192.168.20.11, TCP port 5001 TCP window size: 8.00 KByte (default) ------------------------------------------------------------ [1948] local 192.168.20.22 port 1182 connected with 192.168.20.11 port 5001 [ ID] Interval Transfer Bandwidth [1948] 0.0- 3.1 sec 35.0 MBytes 93.7 Mbits/sec C:\test>iperf.exe -c 192.168.20.11 -n 40M ------------------------------------------------------------ Client connecting to 192.168.20.11, TCP port 5001 TCP window size: 8.00 KByte (default) ------------------------------------------------------------ [1948] local 192.168.20.22 port 1186 connected with 192.168.20.11 port 5001 [ ID] Interval Transfer Bandwidth [1948] 0.0- 3.6 sec 40.0 MBytes 93.8 Mbits/sec C:\test>iperf.exe -c 192.168.20.11 -n 45M ------------------------------------------------------------ Client connecting to 192.168.20.11, TCP port 5001 TCP window size: 8.00 KByte (default) ------------------------------------------------------------ [1948] local 192.168.20.22 port 1189 connected with 192.168.20.11 port 5001 [ ID] Interval Transfer Bandwidth [1948] 0.0- 4.0 sec 45.0 MBytes 93.8 Mbits/sec C:\test>iperf.exe -c 192.168.20.11 -n 50M ------------------------------------------------------------ Client connecting to 192.168.20.11, TCP port 5001 TCP window size: 8.00 KByte (default) ------------------------------------------------------------
86
[1948] local 192.168.20.22 port 1192 connected with 192.168.20.11 port 5001 [ ID] Interval Transfer Bandwidth [1948] 0.0- 4.5 sec 50.0 MBytes 93.9 Mbits/sec C:\test>iperf.exe -c 192.168.20.11 -n 55M ------------------------------------------------------------ Client connecting to 192.168.20.11, TCP port 5001 TCP window size: 8.00 KByte (default) ------------------------------------------------------------ [1948] local 192.168.20.22 port 1194 connected with 192.168.20.11 port 5001 [ ID] Interval Transfer Bandwidth [1948] 0.0- 4.9 sec 55.0 MBytes 94.0 Mbits/sec C:\test>iperf.exe -c 192.168.20.11 -n 60M ------------------------------------------------------------ Client connecting to 192.168.20.11, TCP port 5001 TCP window size: 8.00 KByte (default) ------------------------------------------------------------ [1948] local 192.168.20.22 port 1197 connected with 192.168.20.11 port 5001 [ ID] Interval Transfer Bandwidth [1948] 0.0- 5.4 sec 60.0 MBytes 94.1 Mbits/sec 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 TCP window size: 8.00 KByte (default) ------------------------------------------------------------ [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 [1948] 0.0- 0.0 sec 128 KBytes 52.2 Mbits/sec C:\test>iperf.exe -c 11:11:11:11:11:11:11:11 -n 256K ------------------------------------------------------------ Client connecting to 11:11:11:11:11:11:11:11, TCP port 5001 TCP window size: 8.00 KByte (default) ------------------------------------------------------------ [1948] local 11:11:11:11:11:11:11:22 port 1068 connected with 11:11:11:11:11:11: 11:11 port 5001 [ ID] Interval Transfer Bandwidth [1948] 0.0- 0.0 sec 256 KBytes 69.8 Mbits/sec C:\test>iperf.exe -c 11:11:11:11:11:11:11:11 -n 384K ------------------------------------------------------------ Client connecting to 11:11:11:11:11:11:11:11, TCP port 5001
87
TCP window size: 8.00 KByte (default) ------------------------------------------------------------ [1948] local 11:11:11:11:11:11:11:22 port 1069 connected with 11:11:11:11:11:11: 11:11 port 5001 [ ID] Interval Transfer Bandwidth [1948] 0.0- 0.0 sec 384 KBytes 78.5 Mbits/sec C:\test>iperf.exe -c 11:11:11:11:11:11:11:11 -n 512K ------------------------------------------------------------ Client connecting to 11:11:11:11:11:11:11:11, TCP port 5001 TCP window size: 8.00 KByte (default) ------------------------------------------------------------ [1948] local 11:11:11:11:11:11:11:22 port 1070 connected with 11:11:11:11:11:11: 11:11 port 5001 [ ID] Interval Transfer Bandwidth [1948] 0.0- 0.1 sec 512 KBytes 83.8 Mbits/sec C:\test>iperf.exe -c 11:11:11:11:11:11:11:11 -n 640K ------------------------------------------------------------ Client connecting to 11:11:11:11:11:11:11:11, TCP port 5001 TCP window size: 8.00 KByte (default) ------------------------------------------------------------ [1948] local 11:11:11:11:11:11:11:22 port 1071 connected with 11:11:11:11:11:11: 11:11 port 5001 [ ID] Interval Transfer Bandwidth [1948] 0.0- 0.1 sec 640 KBytes 87.3 Mbits/sec C:\test>iperf.exe -c 11:11:11:11:11:11:11:11 -n 768K ------------------------------------------------------------ Client connecting to 11:11:11:11:11:11:11:11, TCP port 5001 TCP window size: 8.00 KByte (default) ------------------------------------------------------------ [1948] local 11:11:11:11:11:11:11:22 port 1034 connected with 11:11:11:11:11:11: 11:11 port 5001 [ ID] Interval Transfer Bandwidth [1948] 0.0- 0.1 sec 768 KBytes 89.7 Mbits/sec C:\test>iperf.exe -c 11:11:11:11:11:11:11:11 -n 896K ------------------------------------------------------------ Client connecting to 11:11:11:11:11:11:11:11, TCP port 5001 TCP window size: 8.00 KByte (default) ------------------------------------------------------------ [1948] local 11:11:11:11:11:11:11:22 port 1035 connected with 11:11:11:11:11:11: 11:11 port 5001 [ ID] Interval Transfer Bandwidth [1948] 0.0- 0.1 sec 896 KBytes 91.6 Mbits/sec C:\test>iperf.exe -c 11:11:11:11:11:11:11:11 -n 1024K ------------------------------------------------------------ Client connecting to 11:11:11:11:11:11:11:11, TCP port 5001
88
TCP window size: 8.00 KByte (default) ------------------------------------------------------------ [1948] local 11:11:11:11:11:11:11:22 port 1036 connected with 11:11:11:11:11:11: 11:11 port 5001 [ ID] Interval Transfer Bandwidth [1948] 0.0- 0.1 sec 1.00 MBytes 93.1 Mbits/sec C:\test>iperf.exe -c 11:11:11:11:11:11:11:11 -n 1152K ------------------------------------------------------------ Client connecting to 11:11:11:11:11:11:11:11, TCP port 5001 TCP window size: 8.00 KByte (default) ------------------------------------------------------------ [1948] local 11:11:11:11:11:11:11:22 port 1037 connected with 11:11:11:11:11:11: 11:11 port 5001 [ ID] Interval Transfer Bandwidth [1948] 0.0- 0.1 sec 1.13 MBytes 94.2 Mbits/sec C:\test>iperf.exe -c 11:11:11:11:11:11:11:11 -n 1280K ------------------------------------------------------------ Client connecting to 11:11:11:11:11:11:11:11, TCP port 5001 TCP window size: 8.00 KByte (default) ------------------------------------------------------------ [1948] local 11:11:11:11:11:11:11:22 port 1042 connected with 11:11:11:11:11:11: 11:11 port 5001 [ ID] Interval Transfer Bandwidth [1948] 0.0- 0.1 sec 1.25 MBytes 95.2 Mbits/sec C:\test>iperf.exe -c 11:11:11:11:11:11:11:11 -n 1408K ------------------------------------------------------------ Client connecting to 11:11:11:11:11:11:11:11, TCP port 5001 TCP window size: 8.00 KByte (default) ------------------------------------------------------------ [1948] local 11:11:11:11:11:11:11:22 port 1044 connected with 11:11:11:11:11:11: 11:11 port 5001 [ ID] Interval Transfer Bandwidth [1948] 0.0- 0.1 sec 1.38 MBytes 96.0 Mbits/sec C:\test>iperf.exe -c 11:11:11:11:11:11:11:11 -n 5M ------------------------------------------------------------ Client connecting to 11:11:11:11:11:11:11:11, TCP port 5001 TCP window size: 8.00 KByte (default) ------------------------------------------------------------ [1948] local 11:11:11:11:11:11:11:22 port 1045 connected with 11:11:11:11:11:11: 11:11 port 5001 [ ID] Interval Transfer Bandwidth [1948] 0.0- 0.5 sec 5.00 MBytes 91.0 Mbits/sec C:\test>iperf.exe -c 11:11:11:11:11:11:11:11 -n 10M ------------------------------------------------------------ Client connecting to 11:11:11:11:11:11:11:11, TCP port 5001
89
TCP window size: 8.00 KByte (default) ------------------------------------------------------------ [1948] local 11:11:11:11:11:11:11:22 port 1046 connected with 11:11:11:11:11:11: 11:11 port 5001 [ ID] Interval Transfer Bandwidth [1948] 0.0- 0.9 sec 10.0 MBytes 92.0 Mbits/sec C:\test>iperf.exe -c 11:11:11:11:11:11:11:11 -n 15M ------------------------------------------------------------ Client connecting to 11:11:11:11:11:11:11:11, TCP port 5001 TCP window size: 8.00 KByte (default) ------------------------------------------------------------ [1948] local 11:11:11:11:11:11:11:22 port 1047 connected with 11:11:11:11:11:11: 11:11 port 5001 [ ID] Interval Transfer Bandwidth [1948] 0.0- 1.4 sec 15.0 MBytes 92.4 Mbits/sec C:\test>iperf.exe -c 11:11:11:11:11:11:11:11 -n 20M ------------------------------------------------------------ Client connecting to 11:11:11:11:11:11:11:11, TCP port 5001 TCP window size: 8.00 KByte (default) ------------------------------------------------------------ [1948] local 11:11:11:11:11:11:11:22 port 1048 connected with 11:11:11:11:11:11: 11:11 port 5001 [ ID] Interval Transfer Bandwidth [1948] 0.0- 1.8 sec 20.0 MBytes 92.6 Mbits/sec C:\test>iperf.exe -c 11:11:11:11:11:11:11:11 -n 25M ------------------------------------------------------------ Client connecting to 11:11:11:11:11:11:11:11, TCP port 5001 TCP window size: 8.00 KByte (default) ------------------------------------------------------------ [1948] local 11:11:11:11:11:11:11:22 port 1049 connected with 11:11:11:11:11:11: 11:11 port 5001 [ ID] Interval Transfer Bandwidth [1948] 0.0- 2.3 sec 25.0 MBytes 92.7 Mbits/sec C:\test>iperf.exe -c 11:11:11:11:11:11:11:11 -n 30M ------------------------------------------------------------ Client connecting to 11:11:11:11:11:11:11:11, TCP port 5001 TCP window size: 8.00 KByte (default) ------------------------------------------------------------ [1948] local 11:11:11:11:11:11:11:22 port 1050 connected with 11:11:11:11:11:11: 11:11 port 5001 [ ID] Interval Transfer Bandwidth [1948] 0.0- 2.7 sec 30.0 MBytes 92.7 Mbits/sec C:\test>iperf.exe -c 11:11:11:11:11:11:11:11 -n 35M ------------------------------------------------------------ Client connecting to 11:11:11:11:11:11:11:11, TCP port 5001
90
TCP window size: 8.00 KByte (default) ------------------------------------------------------------ [1948] local 11:11:11:11:11:11:11:22 port 1051 connected with 11:11:11:11:11:11: 11:11 port 5001 [ ID] Interval Transfer Bandwidth [1948] 0.0- 3.2 sec 35.0 MBytes 92.8 Mbits/sec C:\test>iperf.exe -c 11:11:11:11:11:11:11:11 -n 40M ------------------------------------------------------------ Client connecting to 11:11:11:11:11:11:11:11, TCP port 5001 TCP window size: 8.00 KByte (default) ------------------------------------------------------------ [1948] local 11:11:11:11:11:11:11:22 port 1052 connected with 11:11:11:11:11:11: 11:11 port 5001 [ ID] Interval Transfer Bandwidth [1948] 0.0- 3.6 sec 40.0 MBytes 92.8 Mbits/sec C:\test>iperf.exe -c 11:11:11:11:11:11:11:11 -n 45M ------------------------------------------------------------ Client connecting to 11:11:11:11:11:11:11:11, TCP port 5001 TCP window size: 8.00 KByte (default) ------------------------------------------------------------ [1948] local 11:11:11:11:11:11:11:22 port 1056 connected with 11:11:11:11:11:11: 11:11 port 5001 [ ID] Interval Transfer Bandwidth [1948] 0.0- 4.1 sec 45.0 MBytes 92.8 Mbits/sec C:\test>iperf.exe -c 11:11:11:11:11:11:11:11 -n 50M ------------------------------------------------------------ Client connecting to 11:11:11:11:11:11:11:11, TCP port 5001 TCP window size: 8.00 KByte (default) ------------------------------------------------------------ [1948] local 11:11:11:11:11:11:11:22 port 1058 connected with 11:11:11:11:11:11: 11:11 port 5001 [ ID] Interval Transfer Bandwidth [1948] 0.0- 4.5 sec 50.0 MBytes 92.9 Mbits/sec C:\test>iperf.exe -c 11:11:11:11:11:11:11:11 -n 55M ------------------------------------------------------------ Client connecting to 11:11:11:11:11:11:11:11, TCP port 5001 TCP window size: 8.00 KByte (default) ------------------------------------------------------------ [1948] local 11:11:11:11:11:11:11:22 port 1060 connected with 11:11:11:11:11:11: 11:11 port 5001 [ ID] Interval Transfer Bandwidth [1948] 0.0- 5.0 sec 55.0 MBytes 92.9 Mbits/sec C:\test>iperf.exe -c 11:11:11:11:11:11:11:11 -n 60M ------------------------------------------------------------ Client connecting to 11:11:11:11:11:11:11:11, TCP port 5001
91
TCP window size: 8.00 KByte (default) ------------------------------------------------------------ [1948] local 11:11:11:11:11:11:11:22 port 1062 connected with 11:11:11:11:11:11: 11:11 port 5001 [ ID] Interval Transfer Bandwidth [1948] 0.0- 5.4 sec 60.0 MBytes 92.9 Mbits/sec C:\test> F.3 UDP version 4 protocol logs from Windows Microsoft Windows [Version 5.2.3790] (C) Copyright 1985-2003 Microsoft Corp. 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) ------------------------------------------------------------ [1964] local 192.168.20.11 port 5001 connected with 192.168.20.22 port 1129 [ 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%) [1964] local 192.168.20.11 port 5001 connected with 192.168.20.22 port 1130 [ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams [1964] 0.0- 0.1 sec 257 KBytes 42.0 Mbits/sec 0.412 ms 0/ 179 (0%) [1964] local 192.168.20.11 port 5001 connected with 192.168.20.22 port 1131 [ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams [1964] 0.0- 0.0 sec 257 KBytes 52.6 Mbits/sec 0.341 ms 0/ 179 (0%) [1964] local 192.168.20.11 port 5001 connected with 192.168.20.22 port 1132 [ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams [1964] 0.0- 0.0 sec 257 KBytes 52.6 Mbits/sec 0.386 ms 0/ 179 (0%) [1964] local 192.168.20.11 port 5001 connected with 192.168.20.22 port 1133 [ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams [1964] 0.0- 0.1 sec 385 KBytes 52.5 Mbits/sec 0.341 ms 0/ 268 (0%) [1964] local 192.168.20.11 port 5001 connected with 192.168.20.22 port 1134 [ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams [1964] 0.0- 0.1 sec 512 KBytes 52.4 Mbits/sec 0.281 ms 0/ 357 (0%) [1964] local 192.168.20.11 port 5001 connected with 192.168.20.22 port 1135 [ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams [1964] 0.0- 0.1 sec 512 KBytes 52.4 Mbits/sec 0.265 ms 0/ 357 (0%) [1964] local 192.168.20.11 port 5001 connected with 192.168.20.22 port 1136 [ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams [1964] 0.0- 0.1 sec 640 KBytes 52.4 Mbits/sec 0.249 ms 0/ 446 (0%) [1964] local 192.168.20.11 port 5001 connected with 192.168.20.22 port 1137 [ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams [1964] 0.0- 0.1 sec 640 KBytes 47.6 Mbits/sec 0.250 ms 0/ 446 (0%) [1964] local 192.168.20.11 port 5001 connected with 192.168.20.22 port 1138
92
[ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams [1964] 0.0- 0.1 sec 614 KBytes 50.3 Mbits/sec 0.235 ms 18/ 446 (4%) [1964] local 192.168.20.11 port 5001 connected with 192.168.20.22 port 1139 [ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams [1964] 0.0- 0.1 sec 629 KBytes 51.4 Mbits/sec 0.235 ms 8/ 446 (1.8%) [1964] local 192.168.20.11 port 5001 connected with 192.168.20.22 port 1140 [ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams [1964] 0.0- 0.1 sec 640 KBytes 52.4 Mbits/sec 0.250 ms 0/ 446 (0%) [1964] local 192.168.20.11 port 5001 connected with 192.168.20.22 port 1141 [ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams [1964] 0.0- 0.1 sec 768 KBytes 52.4 Mbits/sec 0.206 ms 0/ 535 (0%) [1964] local 192.168.20.11 port 5001 connected with 192.168.20.22 port 1142 [ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams [1964] 0.0- 0.1 sec 897 KBytes 52.4 Mbits/sec 0.170 ms 0/ 625 (0%) [1964] local 192.168.20.11 port 5001 connected with 192.168.20.22 port 1143 [ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams [1964] 0.0- 0.1 sec 1.00 MBytes 64.5 Mbits/sec 0.142 ms 0/ 714 (0%) [1964] local 192.168.20.11 port 5001 connected with 192.168.20.22 port 1144 [ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams [1964] 0.0- 0.1 sec 1.13 MBytes 67.4 Mbits/sec 0.196 ms 0/ 803 (0%) [1964] local 192.168.20.11 port 5001 connected with 192.168.20.22 port 1145 [ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams [1964] 0.0- 0.1 sec 1.13 MBytes 67.4 Mbits/sec 0.174 ms 0/ 803 (0%) [1964] local 192.168.20.11 port 5001 connected with 192.168.20.22 port 1146 [ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams [1964] 0.0- 0.1 sec 1.13 MBytes 67.4 Mbits/sec 0.184 ms 0/ 803 (0%) [1964] local 192.168.20.11 port 5001 connected with 192.168.20.22 port 1147 [ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams [1964] 0.0- 0.1 sec 1.11 MBytes 71.6 Mbits/sec 0.184 ms 10/ 803 (1.2%) [1964] local 192.168.20.11 port 5001 connected with 192.168.20.22 port 1148 [ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams [1964] 0.0- 0.2 sec 1.25 MBytes 65.5 Mbits/sec 0.118 ms 0/ 892 (0%) [1964] local 192.168.20.11 port 5001 connected with 192.168.20.22 port 1149 [ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams [1964] 0.0- 0.2 sec 1.24 MBytes 69.1 Mbits/sec 0.111 ms 9/ 892 (1%) [1964] local 192.168.20.11 port 5001 connected with 192.168.20.22 port 1150 [ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams [1964] 0.0- 0.2 sec 1.25 MBytes 69.8 Mbits/sec 0.111 ms 0/ 892 (0%) [1964] local 192.168.20.11 port 5001 connected with 192.168.20.22 port 1151 [ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams [1964] 0.0- 0.2 sec 1.25 MBytes 65.5 Mbits/sec 0.112 ms 0/ 892 (0%) [1964] local 192.168.20.11 port 5001 connected with 192.168.20.22 port 1152 [ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams [1964] 0.0- 0.2 sec 1.25 MBytes 69.8 Mbits/sec 0.112 ms 0/ 892 (0%) [1964] local 192.168.20.11 port 5001 connected with 192.168.20.22 port 1153 [ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams [1964] 0.0- 0.2 sec 1.25 MBytes 69.8 Mbits/sec 0.112 ms 0/ 892 (0%) [1964] local 192.168.20.11 port 5001 connected with 192.168.20.22 port 1154 [ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams [1964] 0.0- 0.2 sec 1.25 MBytes 69.8 Mbits/sec 0.112 ms 0/ 892 (0%)
93
[1964] local 192.168.20.11 port 5001 connected with 192.168.20.22 port 1155 [ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams [1964] 0.0- 0.2 sec 1.25 MBytes 65.5 Mbits/sec 0.112 ms 0/ 892 (0%) [1964] local 192.168.20.11 port 5001 connected with 192.168.20.22 port 1156 [ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams [1964] 0.0- 0.2 sec 1.36 MBytes 71.3 Mbits/sec 0.154 ms 10/ 981 (1%) [1964] local 192.168.20.11 port 5001 connected with 192.168.20.22 port 1157 [ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams [1964] 0.0- 0.2 sec 1.38 MBytes 72.0 Mbits/sec 0.136 ms 0/ 981 (0%) F.4 UDP version 6 protocol logs from Windows Microsoft Windows [Version 5.2.3790] (C) Copyright 1985-2003 Microsoft Corp. 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 Jitter Lost/Total Datagrams [1964] 0.0- 0.0 sec 129 KBytes 35.2 Mbits/sec 0.404 ms 0/ 90 (0%) [1964] local :: port 5001 connected with 11:11:11:11:11:11:11:22 port 1150 [ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams [1964] 0.0- 0.0 sec 257 KBytes 52.6 Mbits/sec 0.318 ms 0/ 179 (0%) [1964] local :: port 5001 connected with 11:11:11:11:11:11:11:22 port 1151 [ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams [1964] 0.0- 0.1 sec 385 KBytes 45.0 Mbits/sec 0.298 ms 0/ 268 (0%) [1964] local :: port 5001 connected with 11:11:11:11:11:11:11:22 port 1152 [ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams [1964] 0.0- 0.1 sec 369 KBytes 43.1 Mbits/sec 0.280 ms 11/ 268 (4.1%) [1964] local :: port 5001 connected with 11:11:11:11:11:11:11:22 port 1153 [ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams [1964] 0.0- 0.1 sec 385 KBytes 52.5 Mbits/sec 0.284 ms 0/ 268 (0%) [1964] local :: port 5001 connected with 11:11:11:11:11:11:11:22 port 1154 [ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams [1964] 0.0- 0.1 sec 500 KBytes 51.1 Mbits/sec 0.234 ms 9/ 357 (2.5%) [1964] local :: port 5001 connected with 11:11:11:11:11:11:11:22 port 1155 [ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams [1964] 0.0- 0.1 sec 512 KBytes 46.6 Mbits/sec 0.254 ms 0/ 357 (0%) [1964] local :: port 5001 connected with 11:11:11:11:11:11:11:22 port 1156 [ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams [1964] 0.0- 0.1 sec 512 KBytes 46.6 Mbits/sec 0.234 ms 0/ 357 (0%) [1964] local :: port 5001 connected with 11:11:11:11:11:11:11:22 port 1157 [ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams
94
[1964] 0.0- 0.1 sec 511 KBytes 52.3 Mbits/sec 0.238 ms 1/ 357 (0.28%) [1964] local :: port 5001 connected with 11:11:11:11:11:11:11:22 port 1158 [ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams [1964] 0.0- 0.1 sec 640 KBytes 52.4 Mbits/sec 0.210 ms 0/ 446 (0%) [1964] local :: port 5001 connected with 11:11:11:11:11:11:11:22 port 1159 [ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams [1964] 0.0- 0.1 sec 768 KBytes 48.3 Mbits/sec 0.176 ms 0/ 535 (0%) [1964] local :: port 5001 connected with 11:11:11:11:11:11:11:22 port 1160 [ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams [1964] 0.0- 0.1 sec 768 KBytes 52.4 Mbits/sec 0.176 ms 0/ 535 (0%) [1964] local :: port 5001 connected with 11:11:11:11:11:11:11:22 port 1161 [ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams [1964] 0.0- 0.1 sec 887 KBytes 51.8 Mbits/sec 0.148 ms 7/ 625 (1.1%) [1964] local :: port 5001 connected with 11:11:11:11:11:11:11:22 port 1162 [ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams [1964] 0.0- 0.1 sec 897 KBytes 52.4 Mbits/sec 0.148 ms 0/ 625 (0%) [1964] local :: port 5001 connected with 11:11:11:11:11:11:11:22 port 1163 [ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams [1964] 0.0- 0.2 sec 1018 KBytes 49.0 Mbits/sec 0.130 ms 5/ 714 (0.7%) [1964] local :: port 5001 connected with 11:11:11:11:11:11:11:22 port 1164 [ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams [1964] 0.0- 0.2 sec 999 KBytes 51.1 Mbits/sec 0.133 ms 18/ 714 (2.5%) [1964] local :: port 5001 connected with 11:11:11:11:11:11:11:22 port 1165 [ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams [1964] 0.0- 0.2 sec 1.00 MBytes 52.4 Mbits/sec 0.132 ms 0/ 714 (0%) [1964] local :: port 5001 connected with 11:11:11:11:11:11:11:22 port 1166 [ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams [1964] 0.0- 0.2 sec 1021 KBytes 52.2 Mbits/sec 0.124 ms 3/ 714 (0.42%) [1964] local :: port 5001 connected with 11:11:11:11:11:11:11:22 port 1167 [ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams [1964] 0.0- 0.2 sec 1.00 MBytes 49.3 Mbits/sec 0.141 ms 0/ 714 (0%) [1964] local :: port 5001 connected with 11:11:11:11:11:11:11:22 port 1168 [ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams [1964] 0.0- 0.2 sec 1009 KBytes 48.6 Mbits/sec 0.132 ms 11/ 714 (1.5%) [1964] local :: port 5001 connected with 11:11:11:11:11:11:11:22 port 1169 [ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams [1964] 0.0- 0.0 sec 172 KBytes 47.0 Mbits/sec 0.132 ms 594/ 714 (83%) [1964] local :: port 5001 connected with 11:11:11:11:11:11:11:22 port 1170 [ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams [1964] 0.0- 0.2 sec 1.00 MBytes 52.4 Mbits/sec 0.132 ms 0/ 714 (0%) [1964] local :: port 5001 connected with 11:11:11:11:11:11:11:22 port 1171 [ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams [1964] 0.0- 0.2 sec 1.13 MBytes 49.6 Mbits/sec 0.109 ms 0/ 803 (0%) [1964] local :: port 5001 connected with 11:11:11:11:11:11:11:22 port 1172 [ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams [1964] 0.0- 0.2 sec 1.13 MBytes 49.6 Mbits/sec 0.109 ms 0/ 803 (0%) [1964] local :: port 5001 connected with 11:11:11:11:11:11:11:22 port 1173 [ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams [1964] 0.0- 0.2 sec 1.11 MBytes 51.5 Mbits/sec 0.109 ms 13/ 803 (1.6%) [1964] local :: port 5001 connected with 11:11:11:11:11:11:11:22 port 1174
95
[ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams [1964] 0.0- 0.2 sec 1.13 MBytes 49.6 Mbits/sec 0.109 ms 0/ 803 (0%) [1964] local :: port 5001 connected with 11:11:11:11:11:11:11:22 port 1175 [ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams [1964] 0.0- 0.2 sec 1.12 MBytes 51.9 Mbits/sec 0.111 ms 7/ 803 (0.87%) [1964] local :: port 5001 connected with 11:11:11:11:11:11:11:22 port 1176 [ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams [1964] 0.0- 0.2 sec 1.13 MBytes 49.6 Mbits/sec 0.116 ms 0/ 803 (0%) [1964] local :: port 5001 connected with 11:11:11:11:11:11:11:22 port 1177 [ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams [1964] 0.0- 0.2 sec 1.13 MBytes 49.6 Mbits/sec 0.111 ms 0/ 803 (0%) [1964] local :: port 5001 connected with 11:11:11:11:11:11:11:22 port 1213 [ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams [1964] 0.0- 0.1 sec 1.00 MBytes 64.5 Mbits/sec 0.785 ms 0/ 714 (0%) [1964] local :: port 5001 connected with 11:11:11:11:11:11:11:22 port 1214 [ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams [1964] 0.0- 0.1 sec 1.13 MBytes 67.4 Mbits/sec 0.284 ms 0/ 803 (0%) [1964] local :: port 5001 connected with 11:11:11:11:11:11:11:22 port 1215 [ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams [1964] 0.0- 0.2 sec 1.25 MBytes 65.5 Mbits/sec 0.674 ms 0/ 892 (0%) [1964] local :: port 5001 connected with 11:11:11:11:11:11:11:22 port 1216 [ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams [1964] 0.0- 0.2 sec 1.25 MBytes 65.5 Mbits/sec 0.719 ms 0/ 892 (0%) [1964] local :: port 5001 connected with 11:11:11:11:11:11:11:22 port 1217 [ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams [1964] 0.0- 0.2 sec 1.38 MBytes 67.8 Mbits/sec 0.244 ms 0/ 981 (0%) F.5 TCP version 4 protocol logs from Linux ------------------------------------------------------------ Client connecting to 192.168.20.11, TCP port 5001 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 ------------------------------------------------------------ Client connecting to 192.168.20.11, TCP port 5001 TCP window size: 16.0 KByte (WARNING: requested 8.00 KByte) ------------------------------------------------------------ [ 3] local 192.168.20.22 port 32800 connected with 192.168.20.11 port 5001 [ 3] 0.0- 0.0 sec 256 KBytes 95.4 Mbits/sec ------------------------------------------------------------ Client connecting to 192.168.20.11, TCP port 5001 TCP window size: 16.0 KByte (WARNING: requested 8.00 KByte) ------------------------------------------------------------ [ 3] local 192.168.20.22 port 32805 connected with 192.168.20.11 port 5001 [ 3] 0.0- 0.0 sec 384 KBytes 95.7 Mbits/sec ------------------------------------------------------------ Client connecting to 192.168.20.11, TCP port 5001 TCP window size: 16.0 KByte (WARNING: requested 8.00 KByte)
96
------------------------------------------------------------ [ 3] local 192.168.20.22 port 32810 connected with 192.168.20.11 port 5001 [ 3] 0.0- 0.0 sec 512 KBytes 95.3 Mbits/sec ------------------------------------------------------------ Client connecting to 192.168.20.11, TCP port 5001 TCP window size: 16.0 KByte (WARNING: requested 8.00 KByte) ------------------------------------------------------------ [ 3] local 192.168.20.22 port 32815 connected with 192.168.20.11 port 5001 [ 3] 0.0- 0.1 sec 640 KBytes 94.8 Mbits/sec ------------------------------------------------------------ Client connecting to 192.168.20.11, TCP port 5001 TCP window size: 16.0 KByte (WARNING: requested 8.00 KByte) ------------------------------------------------------------ [ 3] local 192.168.20.22 port 32820 connected with 192.168.20.11 port 5001 [ 3] 0.0- 0.1 sec 768 KBytes 94.7 Mbits/sec ------------------------------------------------------------ Client connecting to 192.168.20.11, TCP port 5001 TCP window size: 16.0 KByte (WARNING: requested 8.00 KByte) ------------------------------------------------------------ [ 3] local 192.168.20.22 port 32825 connected with 192.168.20.11 port 5001 [ 3] 0.0- 0.1 sec 896 KBytes 94.6 Mbits/sec ------------------------------------------------------------ Client connecting to 192.168.20.11, TCP port 5001 TCP window size: 16.0 KByte (WARNING: requested 8.00 KByte) ------------------------------------------------------------ [ 3] local 192.168.20.22 port 32830 connected with 192.168.20.11 port 5001 [ 3] 0.0- 0.1 sec 1.00 MBytes 94.7 Mbits/sec ------------------------------------------------------------ Client connecting to 192.168.20.11, TCP port 5001 TCP window size: 16.0 KByte (WARNING: requested 8.00 KByte) ------------------------------------------------------------ [ 3] local 192.168.20.22 port 32831 connected with 192.168.20.11 port 5001 [ 3] 0.0- 0.1 sec 1.12 MBytes 94.3 Mbits/sec ------------------------------------------------------------ Client connecting to 192.168.20.11, TCP port 5001 TCP window size: 16.0 KByte (WARNING: requested 8.00 KByte) ------------------------------------------------------------ [ 3] local 192.168.20.22 port 32840 connected with 192.168.20.11 port 5001 [ 3] 0.0- 0.1 sec 1.25 MBytes 94.2 Mbits/sec ------------------------------------------------------------ Client connecting to 192.168.20.11, TCP port 5001 TCP window size: 16.0 KByte (WARNING: requested 8.00 KByte) ------------------------------------------------------------ [ 3] local 192.168.20.22 port 32845 connected with 192.168.20.11 port 5001 [ 3] 0.0- 0.1 sec 1.38 MBytes 94.3 Mbits/sec ------------------------------------------------------------ Client connecting to 192.168.20.11, TCP port 5001 TCP window size: 16.0 KByte (WARNING: requested 8.00 KByte) ------------------------------------------------------------ [ 3] local 192.168.20.22 port 32846 connected with 192.168.20.11 port 5001
97
[ 3] 0.0- 0.4 sec 5.00 MBytes 93.9 Mbits/sec ------------------------------------------------------------ Client connecting to 192.168.20.11, TCP port 5001 TCP window size: 16.0 KByte (WARNING: requested 8.00 KByte) ------------------------------------------------------------ [ 3] local 192.168.20.22 port 32851 connected with 192.168.20.11 port 5001 [ 3] 0.0- 0.9 sec 10.0 MBytes 93.8 Mbits/sec ------------------------------------------------------------ Client connecting to 192.168.20.11, TCP port 5001 TCP window size: 16.0 KByte (WARNING: requested 8.00 KByte) ------------------------------------------------------------ [ 3] local 192.168.20.22 port 32856 connected with 192.168.20.11 port 5001 [ 3] 0.0- 1.3 sec 15.0 MBytes 93.8 Mbits/sec ------------------------------------------------------------ Client connecting to 192.168.20.11, TCP port 5001 TCP window size: 16.0 KByte (WARNING: requested 8.00 KByte) ------------------------------------------------------------ [ 3] local 192.168.20.22 port 32865 connected with 192.168.20.11 port 5001 [ 3] 0.0- 1.8 sec 20.0 MBytes 93.7 Mbits/sec ------------------------------------------------------------ Client connecting to 192.168.20.11, TCP port 5001 TCP window size: 16.0 KByte (WARNING: requested 8.00 KByte) ------------------------------------------------------------ [ 3] local 192.168.20.22 port 32870 connected with 192.168.20.11 port 5001 [ 3] 0.0- 2.2 sec 25.0 MBytes 93.7 Mbits/sec ------------------------------------------------------------ Client connecting to 192.168.20.11, TCP port 5001 TCP window size: 16.0 KByte (WARNING: requested 8.00 KByte) ------------------------------------------------------------ [ 3] local 192.168.20.22 port 32875 connected with 192.168.20.11 port 5001 [ 3] 0.0- 2.7 sec 30.0 MBytes 93.7 Mbits/sec ------------------------------------------------------------ Client connecting to 192.168.20.11, TCP port 5001 TCP window size: 16.0 KByte (WARNING: requested 8.00 KByte) ------------------------------------------------------------ [ 3] local 192.168.20.22 port 32876 connected with 192.168.20.11 port 5001 [ 3] 0.0- 3.1 sec 35.0 MBytes 93.7 Mbits/sec ------------------------------------------------------------ Client connecting to 192.168.20.11, TCP port 5001 TCP window size: 16.0 KByte (WARNING: requested 8.00 KByte) ------------------------------------------------------------ [ 3] local 192.168.20.22 port 32885 connected with 192.168.20.11 port 5001 [ 3] 0.0- 3.6 sec 40.0 MBytes 93.7 Mbits/sec ------------------------------------------------------------ Client connecting to 192.168.20.11, TCP port 5001 TCP window size: 16.0 KByte (WARNING: requested 8.00 KByte) ------------------------------------------------------------ [ 3] local 192.168.20.22 port 32886 connected with 192.168.20.11 port 5001 [ 3] 0.0- 4.0 sec 45.0 MBytes 93.9 Mbits/sec ------------------------------------------------------------
98
Client connecting to 192.168.20.11, TCP port 5001 TCP window size: 16.0 KByte (WARNING: requested 8.00 KByte) ------------------------------------------------------------ [ 3] local 192.168.20.22 port 32892 connected with 192.168.20.11 port 5001 [ 3] 0.0- 4.5 sec 50.0 MBytes 93.9 Mbits/sec ------------------------------------------------------------ Client connecting to 192.168.20.11, TCP port 5001 TCP window size: 16.0 KByte (WARNING: requested 8.00 KByte) ------------------------------------------------------------ [ 3] local 192.168.20.22 port 32897 connected with 192.168.20.11 port 5001 [ 3] 0.0- 4.9 sec 55.0 MBytes 95.0 Mbits/sec ------------------------------------------------------------ Client connecting to 192.168.20.11, TCP port 5001 TCP window size: 16.0 KByte (WARNING: requested 8.00 KByte) ------------------------------------------------------------ [ 3] local 192.168.20.22 port 32906 connected with 192.168.20.11 port 5001 [ 3] 0.0- 5.4 sec 60.0 MBytes 95.0 Mbits/sec F.6 TCP version 6 protocol logs from Linux ------------------------------------------------------------ Client connecting to 11:11:11:11:11:11:11:11, TCP port 5001 TCP window size: 16.0 KByte (WARNING: requested 8.00 KByte) ------------------------------------------------------------ [ 3] local 11:11:11:11:11:11:11:22 port 32920 connected with 11:11:11:11:11:11:11:11 port 5001 [ 3] 0.0- 0.0 sec 128 KBytes 97.1 Mbits/sec ------------------------------------------------------------ Client connecting to 11:11:11:11:11:11:11:11, TCP port 5001 TCP window size: 16.0 KByte (WARNING: requested 8.00 KByte) ------------------------------------------------------------ [ 3] local 11:11:11:11:11:11:11:22 port 32925 connected with 11:11:11:11:11:11:11:11 port 5001 [ 3] 0.0- 0.0 sec 256 KBytes 95.2 Mbits/sec ------------------------------------------------------------ Client connecting to 11:11:11:11:11:11:11:11, TCP port 5001 TCP window size: 16.0 KByte (WARNING: requested 8.00 KByte) ------------------------------------------------------------ [ 3] local 11:11:11:11:11:11:11:22 port 32930 connected with 11:11:11:11:11:11:11:11 port 5001 [ 3] 0.0- 0.0 sec 384 KBytes 94.6 Mbits/sec ------------------------------------------------------------ Client connecting to 11:11:11:11:11:11:11:11, TCP port 5001 TCP window size: 16.0 KByte (WARNING: requested 8.00 KByte) ------------------------------------------------------------ [ 3] local 11:11:11:11:11:11:11:22 port 32935 connected with 11:11:11:11:11:11:11:11 port 5001 [ 3] 0.0- 0.0 sec 512 KBytes 94.0 Mbits/sec -----------------------------------------------------------
99
Client connecting to 11:11:11:11:11:11:11:11, TCP port 5001 TCP window size: 16.0 KByte (WARNING: requested 8.00 KByte) ------------------------------------------------------------ [ 3] local 11:11:11:11:11:11:11:22 port 32940 connected with 11:11:11:11:11:11:11:11 port 5001 [ 3] 0.0- 0.1 sec 640 KBytes 93.7 Mbits/sec ------------------------------------------------------------ Client connecting to 11:11:11:11:11:11:11:11, TCP port 5001 TCP window size: 16.0 KByte (WARNING: requested 8.00 KByte) ------------------------------------------------------------ [ 3] local 11:11:11:11:11:11:11:22 port 32945 connected with 11:11:11:11:11:11:11:11 port 5001 [ 3] 0.0- 0.1 sec 768 KBytes 93.6 Mbits/sec ------------------------------------------------------------ Client connecting to 11:11:11:11:11:11:11:11, TCP port 5001 TCP window size: 16.0 KByte (WARNING: requested 8.00 KByte) ------------------------------------------------------------ [ 3] local 11:11:11:11:11:11:11:22 port 32950 connected with 11:11:11:11:11:11:11:11 port 5001 [ 3] 0.0- 0.1 sec 896 KBytes 93.4 Mbits/sec ------------------------------------------------------------ Client connecting to 11:11:11:11:11:11:11:11, TCP port 5001 TCP window size: 16.0 KByte (WARNING: requested 8.00 KByte) ------------------------------------------------------------ [ 3] local 11:11:11:11:11:11:11:22 port 32955 connected with 11:11:11:11:11:11:11:11 port 5001 [ 3] 0.0- 0.1 sec 1.00 MBytes 93.1 Mbits/sec ------------------------------------------------------------ Client connecting to 11:11:11:11:11:11:11:11, TCP port 5001 TCP window size: 16.0 KByte (WARNING: requested 8.00 KByte) ------------------------------------------------------------ [ 3] local 11:11:11:11:11:11:11:22 port 32961 connected with 11:11:11:11:11:11:11:11 port 5001 [ 3] 0.0- 0.1 sec 1.12 MBytes 93.2 Mbits/sec ------------------------------------------------------------ Client connecting to 11:11:11:11:11:11:11:11, TCP port 5001 TCP window size: 16.0 KByte (WARNING: requested 8.00 KByte) ------------------------------------------------------------ [ 3] local 11:11:11:11:11:11:11:22 port 32962 connected with 11:11:11:11:11:11:11:11 port 5001 [ 3] 0.0- 0.1 sec 1.25 MBytes 93.1 Mbits/sec ------------------------------------------------------------ Client connecting to 11:11:11:11:11:11:11:11, TCP port 5001 TCP window size: 16.0 KByte (WARNING: requested 8.00 KByte) ------------------------------------------------------------ [ 3] local 11:11:11:11:11:11:11:22 port 32963 connected with 11:11:11:11:11:11:11:11 port 5001 [ 3] 0.0- 0.1 sec 1.25 MBytes 93.0 Mbits/sec ------------------------------------------------------------ Client connecting to 11:11:11:11:11:11:11:11, TCP port 5001
100
TCP window size: 16.0 KByte (WARNING: requested 8.00 KByte) ------------------------------------------------------------ [ 3] local 11:11:11:11:11:11:11:22 port 32964 connected with 11:11:11:11:11:11:11:11 port 5001 [ 3] 0.0- 0.1 sec 1.25 MBytes 92.9 Mbits/sec ------------------------------------------------------------ Client connecting to 11:11:11:11:11:11:11:11, TCP port 5001 TCP window size: 16.0 KByte (WARNING: requested 8.00 KByte) ------------------------------------------------------------ [ 3] local 11:11:11:11:11:11:11:22 port 32965 connected with 11:11:11:11:11:11:11:11 port 5001 [ 3] 0.0- 0.1 sec 1.25 MBytes 92.9 Mbits/sec ------------------------------------------------------------ Client connecting to 11:11:11:11:11:11:11:11, TCP port 5001 TCP window size: 16.0 KByte (WARNING: requested 8.00 KByte) ------------------------------------------------------------ [ 3] local 11:11:11:11:11:11:11:22 port 32966 connected with 11:11:11:11:11:11:11:11 port 5001 [ 3] 0.0- 0.1 sec 1.25 MBytes 93.1 Mbits/sec ------------------------------------------------------------ Client connecting to 11:11:11:11:11:11:11:11, TCP port 5001 TCP window size: 16.0 KByte (WARNING: requested 8.00 KByte) ------------------------------------------------------------ [ 3] local 11:11:11:11:11:11:11:22 port 32967 connected with 11:11:11:11:11:11:11:11 port 5001 [ 3] 0.0- 0.1 sec 1.38 MBytes 93.1 Mbits/sec ------------------------------------------------------------ Client connecting to 11:11:11:11:11:11:11:11, TCP port 5001 TCP window size: 16.0 KByte (WARNING: requested 8.00 KByte) ------------------------------------------------------------ [ 3] local 11:11:11:11:11:11:11:22 port 32968 connected with 11:11:11:11:11:11:11:11 port 5001 [ 3] 0.0- 0.1 sec 1.38 MBytes 92.8 Mbits/sec ------------------------------------------------------------ Client connecting to 11:11:11:11:11:11:11:11, TCP port 5001 TCP window size: 16.0 KByte (WARNING: requested 8.00 KByte) ------------------------------------------------------------ [ 3] local 11:11:11:11:11:11:11:22 port 32969 connected with 11:11:11:11:11:11:11:11 port 5001 [ 3] 0.0- 0.1 sec 1.38 MBytes 93.1 Mbits/sec ------------------------------------------------------------ Client connecting to 11:11:11:11:11:11:11:11, TCP port 5001 TCP window size: 16.0 KByte (WARNING: requested 8.00 KByte) ------------------------------------------------------------ [ 3] local 11:11:11:11:11:11:11:22 port 32970 connected with 11:11:11:11:11:11:11:11 port 5001 [ 3] 0.0- 0.1 sec 1.38 MBytes 93.1 Mbits/sec ------------------------------------------------------------ Client connecting to 11:11:11:11:11:11:11:11, TCP port 5001 TCP window size: 16.0 KByte (WARNING: requested 8.00 KByte)
101
------------------------------------------------------------ [ 3] local 11:11:11:11:11:11:11:22 port 32971 connected with 11:11:11:11:11:11:11:11 port 5001 [ 3] 0.0- 0.1 sec 1.38 MBytes 93.1 Mbits/sec ------------------------------------------------------------ Client connecting to 11:11:11:11:11:11:11:11, TCP port 5001 TCP window size: 16.0 KByte (WARNING: requested 8.00 KByte) ------------------------------------------------------------ [ 3] local 11:11:11:11:11:11:11:22 port 32972 connected with 11:11:11:11:11:11:11:11 port 5001 [ 3] 0.0- 0.5 sec 5.00 MBytes 92.7 Mbits/sec ------------------------------------------------------------ Client connecting to 11:11:11:11:11:11:11:11, TCP port 5001 TCP window size: 16.0 KByte (WARNING: requested 8.00 KByte) ------------------------------------------------------------ [ 3] local 11:11:11:11:11:11:11:22 port 32973 connected with 11:11:11:11:11:11:11:11 port 5001 [ 3] 0.0- 0.5 sec 5.00 MBytes 92.7 Mbits/sec ------------------------------------------------------------ Client connecting to 11:11:11:11:11:11:11:11, TCP port 5001 TCP window size: 16.0 KByte (WARNING: requested 8.00 KByte) ------------------------------------------------------------ [ 3] local 11:11:11:11:11:11:11:22 port 32974 connected with 11:11:11:11:11:11:11:11 port 5001 [ 3] 0.0- 0.5 sec 5.00 MBytes 92.7 Mbits/sec ------------------------------------------------------------ Client connecting to 11:11:11:11:11:11:11:11, TCP port 5001 TCP window size: 16.0 KByte (WARNING: requested 8.00 KByte) ------------------------------------------------------------ [ 3] local 11:11:11:11:11:11:11:22 port 32975 connected with 11:11:11:11:11:11:11:11 port 5001 [ 3] 0.0- 0.5 sec 5.00 MBytes 92.7 Mbits/sec ------------------------------------------------------------ Client connecting to 11:11:11:11:11:11:11:11, TCP port 5001 TCP window size: 16.0 KByte (WARNING: requested 8.00 KByte) ------------------------------------------------------------ [ 3] local 11:11:11:11:11:11:11:22 port 32976 connected with 11:11:11:11:11:11:11:11 port 5001 [ 3] 0.0- 0.5 sec 5.00 MBytes 92.7 Mbits/sec ------------------------------------------------------------ Client connecting to 11:11:11:11:11:11:11:11, TCP port 5001 TCP window size: 16.0 KByte (WARNING: requested 8.00 KByte) ------------------------------------------------------------ [ 3] local 11:11:11:11:11:11:11:22 port 32977 connected with 11:11:11:11:11:11:11:11 port 5001 [ 3] 0.0- 0.9 sec 10.0 MBytes 92.6 Mbits/sec ------------------------------------------------------------ Client connecting to 11:11:11:11:11:11:11:11, TCP port 5001 TCP window size: 16.0 KByte (WARNING: requested 8.00 KByte) ------------------------------------------------------------
102
[ 3] local 11:11:11:11:11:11:11:22 port 32978 connected with 11:11:11:11:11:11:11:11 port 5001 [ 3] 0.0- 0.9 sec 10.0 MBytes 92.6 Mbits/sec ------------------------------------------------------------ Client connecting to 11:11:11:11:11:11:11:11, TCP port 5001 TCP window size: 16.0 KByte (WARNING: requested 8.00 KByte) ------------------------------------------------------------ [ 3] local 11:11:11:11:11:11:11:22 port 32979 connected with 11:11:11:11:11:11:11:11 port 5001 [ 3] 0.0- 0.9 sec 10.0 MBytes 92.6 Mbits/sec ------------------------------------------------------------ Client connecting to 11:11:11:11:11:11:11:11, TCP port 5001 TCP window size: 16.0 KByte (WARNING: requested 8.00 KByte) ------------------------------------------------------------ [ 3] local 11:11:11:11:11:11:11:22 port 32980 connected with 11:11:11:11:11:11:11:11 port 5001 [ 3] 0.0- 0.9 sec 10.0 MBytes 92.6 Mbits/sec ------------------------------------------------------------ Client connecting to 11:11:11:11:11:11:11:11, TCP port 5001 TCP window size: 16.0 KByte (WARNING: requested 8.00 KByte) ------------------------------------------------------------ [ 3] local 11:11:11:11:11:11:11:22 port 32981 connected with 11:11:11:11:11:11:11:11 port 5001 [ 3] 0.0- 0.9 sec 10.0 MBytes 92.6 Mbits/sec ------------------------------------------------------------ Client connecting to 11:11:11:11:11:11:11:11, TCP port 5001 TCP window size: 16.0 KByte (WARNING: requested 8.00 KByte) ------------------------------------------------------------ [ 3] local 11:11:11:11:11:11:11:22 port 32982 connected with 11:11:11:11:11:11:11:11 port 5001 [ 3] 0.0- 1.4 sec 15.0 MBytes 92.6 Mbits/sec ------------------------------------------------------------ Client connecting to 11:11:11:11:11:11:11:11, TCP port 5001 TCP window size: 16.0 KByte (WARNING: requested 8.00 KByte) ------------------------------------------------------------ [ 3] local 11:11:11:11:11:11:11:22 port 32983 connected with 11:11:11:11:11:11:11:11 port 5001 [ 3] 0.0- 1.4 sec 15.0 MBytes 92.6 Mbits/sec ------------------------------------------------------------ Client connecting to 11:11:11:11:11:11:11:11, TCP port 5001 TCP window size: 16.0 KByte (WARNING: requested 8.00 KByte) ------------------------------------------------------------ [ 3] local 11:11:11:11:11:11:11:22 port 32984 connected with 11:11:11:11:11:11:11:11 port 5001 [ 3] 0.0- 1.4 sec 15.0 MBytes 92.6 Mbits/sec ------------------------------------------------------------ Client connecting to 11:11:11:11:11:11:11:11, TCP port 5001 TCP window size: 16.0 KByte (WARNING: requested 8.00 KByte) ------------------------------------------------------------
103
[ 3] local 11:11:11:11:11:11:11:22 port 32985 connected with 11:11:11:11:11:11:11:11 port 5001 [ 3] 0.0- 1.4 sec 15.0 MBytes 92.6 Mbits/sec ------------------------------------------------------------ Client connecting to 11:11:11:11:11:11:11:11, TCP port 5001 TCP window size: 16.0 KByte (WARNING: requested 8.00 KByte) ------------------------------------------------------------ [ 3] local 11:11:11:11:11:11:11:22 port 32986 connected with 11:11:11:11:11:11:11:11 port 5001 [ 3] 0.0- 1.4 sec 15.0 MBytes 92.6 Mbits/sec ------------------------------------------------------------ Client connecting to 11:11:11:11:11:11:11:11, TCP port 5001 TCP window size: 16.0 KByte (WARNING: requested 8.00 KByte) ------------------------------------------------------------ [ 3] local 11:11:11:11:11:11:11:22 port 32987 connected with 11:11:11:11:11:11:11:11 port 5001 [ 3] 0.0- 1.8 sec 20.0 MBytes 92.6 Mbits/sec ------------------------------------------------------------ Client connecting to 11:11:11:11:11:11:11:11, TCP port 5001 TCP window size: 16.0 KByte (WARNING: requested 8.00 KByte) ------------------------------------------------------------ [ 3] local 11:11:11:11:11:11:11:22 port 32988 connected with 11:11:11:11:11:11:11:11 port 5001 [ 3] 0.0- 1.8 sec 20.0 MBytes 92.6 Mbits/sec ------------------------------------------------------------ Client connecting to 11:11:11:11:11:11:11:11, TCP port 5001 TCP window size: 16.0 KByte (WARNING: requested 8.00 KByte) ------------------------------------------------------------ [ 3] local 11:11:11:11:11:11:11:22 port 32989 connected with 11:11:11:11:11:11:11:11 port 5001 [ 3] 0.0- 1.8 sec 20.0 MBytes 92.6 Mbits/sec ------------------------------------------------------------ Client connecting to 11:11:11:11:11:11:11:11, TCP port 5001 TCP window size: 16.0 KByte (WARNING: requested 8.00 KByte) ------------------------------------------------------------ [ 3] local 11:11:11:11:11:11:11:22 port 32990 connected with 11:11:11:11:11:11:11:11 port 5001 [ 3] 0.0- 1.8 sec 20.0 MBytes 92.6 Mbits/sec ------------------------------------------------------------ Client connecting to 11:11:11:11:11:11:11:11, TCP port 5001 TCP window size: 16.0 KByte (WARNING: requested 8.00 KByte) ------------------------------------------------------------ [ 3] local 11:11:11:11:11:11:11:22 port 32991 connected with 11:11:11:11:11:11:11:11 port 5001 [ 3] 0.0- 1.8 sec 20.0 MBytes 92.6 Mbits/sec ------------------------------------------------------------ Client connecting to 11:11:11:11:11:11:11:11, TCP port 5001 TCP window size: 16.0 KByte (WARNING: requested 8.00 KByte) ------------------------------------------------------------
104
[ 3] local 11:11:11:11:11:11:11:22 port 32992 connected with 11:11:11:11:11:11:11:11 port 5001 [ 3] 0.0- 2.3 sec 25.0 MBytes 92.6 Mbits/sec ------------------------------------------------------------ Client connecting to 11:11:11:11:11:11:11:11, TCP port 5001 TCP window size: 16.0 KByte (WARNING: requested 8.00 KByte) ------------------------------------------------------------ [ 3] local 11:11:11:11:11:11:11:22 port 32993 connected with 11:11:11:11:11:11:11:11 port 5001 [ 3] 0.0- 2.3 sec 25.0 MBytes 92.6 Mbits/sec ------------------------------------------------------------ Client connecting to 11:11:11:11:11:11:11:11, TCP port 5001 TCP window size: 16.0 KByte (WARNING: requested 8.00 KByte) ------------------------------------------------------------ [ 3] local 11:11:11:11:11:11:11:22 port 32994 connected with 11:11:11:11:11:11:11:11 port 5001 [ 3] 0.0- 2.3 sec 25.0 MBytes 92.6 Mbits/sec ------------------------------------------------------------ Client connecting to 11:11:11:11:11:11:11:11, TCP port 5001 TCP window size: 16.0 KByte (WARNING: requested 8.00 KByte) ------------------------------------------------------------ [ 3] local 11:11:11:11:11:11:11:22 port 32995 connected with 11:11:11:11:11:11:11:11 port 5001 [ 3] 0.0- 2.3 sec 25.0 MBytes 92.6 Mbits/sec ------------------------------------------------------------ Client connecting to 11:11:11:11:11:11:11:11, TCP port 5001 TCP window size: 16.0 KByte (WARNING: requested 8.00 KByte) ------------------------------------------------------------ [ 3] local 11:11:11:11:11:11:11:22 port 32996 connected with 11:11:11:11:11:11:11:11 port 5001 [ 3] 0.0- 2.3 sec 25.0 MBytes 92.6 Mbits/sec ------------------------------------------------------------ Client connecting to 11:11:11:11:11:11:11:11, TCP port 5001 TCP window size: 16.0 KByte (WARNING: requested 8.00 KByte) ------------------------------------------------------------ [ 3] local 11:11:11:11:11:11:11:22 port 32997 connected with 11:11:11:11:11:11:11:11 port 5001 [ 3] 0.0- 2.7 sec 30.0 MBytes 92.6 Mbits/sec ------------------------------------------------------------ Client connecting to 11:11:11:11:11:11:11:11, TCP port 5001 TCP window size: 16.0 KByte (WARNING: requested 8.00 KByte) ------------------------------------------------------------ [ 3] local 11:11:11:11:11:11:11:22 port 32998 connected with 11:11:11:11:11:11:11:11 port 5001 [ 3] 0.0- 2.7 sec 30.0 MBytes 92.6 Mbits/sec ------------------------------------------------------------ Client connecting to 11:11:11:11:11:11:11:11, TCP port 5001 TCP window size: 16.0 KByte (WARNING: requested 8.00 KByte) ------------------------------------------------------------
105
[ 3] local 11:11:11:11:11:11:11:22 port 32999 connected with 11:11:11:11:11:11:11:11 port 5001 [ 3] 0.0- 2.7 sec 30.0 MBytes 92.6 Mbits/sec ------------------------------------------------------------ Client connecting to 11:11:11:11:11:11:11:11, TCP port 5001 TCP window size: 16.0 KByte (WARNING: requested 8.00 KByte) ------------------------------------------------------------ [ 3] local 11:11:11:11:11:11:11:22 port 32771 connected with 11:11:11:11:11:11:11:11 port 5001 [ 3] 0.0-2.7 sec 30.0 MBytes 92.6 Mbits/sec ------------------------------------------------------------ Client connecting to 11:11:11:11:11:11:11:11, TCP port 5001 TCP window size: 16.0 KByte (WARNING: requested 8.00 KByte) ------------------------------------------------------------ [ 3] local 11:11:11:11:11:11:11:22 port 32772 connected with 11:11:11:11:11:11:11:11 port 5001 [ 3] 0.0-2.7 sec 30.0 MBytes 92.6 Mbits/sec ------------------------------------------------------------ Client connecting to 11:11:11:11:11:11:11:11, TCP port 5001 TCP window size: 16.0 KByte (WARNING: requested 8.00 KByte) ------------------------------------------------------------ [ 3] local 11:11:11:11:11:11:11:22 port 32773 connected with 11:11:11:11:11:11:11:11 port 5001 [ 3] 0.0-2.7 sec 30.0 MBytes 92.6 Mbits/sec ------------------------------------------------------------ Client connecting to 11:11:11:11:11:11:11:11, TCP port 5001 TCP window size: 16.0 KByte (WARNING: requested 8.00 KByte) ------------------------------------------------------------ [ 3] local 11:11:11:11:11:11:11:22 port 32774 connected with 11:11:11:11:11:11:11:11 port 5001 [ 3] 0.0-2.7 sec 30.0 MBytes 92.6 Mbits/sec ------------------------------------------------------------ Client connecting to 11:11:11:11:11:11:11:11, TCP port 5001 TCP window size: 16.0 KByte (WARNING: requested 8.00 KByte) ------------------------------------------------------------ [ 3] local 11:11:11:11:11:11:11:22 port 32775 connected with 11:11:11:11:11:11:11:11 port 5001 [ 3] 0.0-3.1 sec 35.0 MBytes 92.6 Mbits/sec ------------------------------------------------------------ Client connecting to 11:11:11:11:11:11:11:11, TCP port 5001 TCP window size: 16.0 KByte (WARNING: requested 8.00 KByte) ------------------------------------------------------------ [ 3] local 11:11:11:11:11:11:11:22 port 32776 connected with 11:11:11:11:11:11:11:11 port 5001 [ 3] 0.0-3.1 sec 35.0 MBytes 92.6 Mbits/sec ------------------------------------------------------------ Client connecting to 11:11:11:11:11:11:11:11, TCP port 5001 TCP window size: 16.0 KByte (WARNING: requested 8.00 KByte) ------------------------------------------------------------
106
[ 3] local 11:11:11:11:11:11:11:22 port 32777 connected with 11:11:11:11:11:11:11:11 port 5001 [ 3] 0.0-3.1 sec 35.0 MBytes 92.6 Mbits/sec ------------------------------------------------------------ Client connecting to 11:11:11:11:11:11:11:11, TCP port 5001 TCP window size: 16.0 KByte (WARNING: requested 8.00 KByte) ------------------------------------------------------------ [ 3] local 11:11:11:11:11:11:11:22 port 32778 connected with 11:11:11:11:11:11:11:11 port 5001 [ 3] 0.0-3.1 sec 35.0 MBytes 92.6 Mbits/sec ------------------------------------------------------------ Client connecting to 11:11:11:11:11:11:11:11, TCP port 5001 TCP window size: 16.0 KByte (WARNING: requested 8.00 KByte) ------------------------------------------------------------ [ 3] local 11:11:11:11:11:11:11:22 port 32779 connected with 11:11:11:11:11:11:11:11 port 5001 [ 3] 0.0-3.1 sec 35.0 MBytes 92.6 Mbits/sec ------------------------------------------------------------ Client connecting to 11:11:11:11:11:11:11:11, TCP port 5001 TCP window size: 16.0 KByte (WARNING: requested 8.00 KByte) ------------------------------------------------------------ [ 3] local 11:11:11:11:11:11:11:22 port 32780 connected with 11:11:11:11:11:11:11:11 port 5001 [ 3] 0.0-3.6 sec 40.0 MBytes 92.6 Mbits/sec ------------------------------------------------------------ Client connecting to 11:11:11:11:11:11:11:11, TCP port 5001 TCP window size: 16.0 KByte (WARNING: requested 8.00 KByte) ------------------------------------------------------------ [ 3] local 11:11:11:11:11:11:11:22 port 32781 connected with 11:11:11:11:11:11:11:11 port 5001 [ 3] 0.0-3.6 sec 40.0 MBytes 92.6 Mbits/sec ------------------------------------------------------------ Client connecting to 11:11:11:11:11:11:11:11, TCP port 5001 TCP window size: 16.0 KByte (WARNING: requested 8.00 KByte) ------------------------------------------------------------ [ 3] local 11:11:11:11:11:11:11:22 port 32782 connected with 11:11:11:11:11:11:11:11 port 5001 [ 3] 0.0-4.0 sec 45.0 MBytes 92.6 Mbits/sec ------------------------------------------------------------ Client connecting to 11:11:11:11:11:11:11:11, TCP port 5001 TCP window size: 16.0 KByte (WARNING: requested 8.00 KByte) ------------------------------------------------------------ [ 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 ------------------------------------------------------------ Client connecting to 11:11:11:11:11:11:11:11, TCP port 5001 TCP window size: 16.0 KByte (WARNING: requested 8.00 KByte) ------------------------------------------------------------ [ 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
107
------------------------------------------------------------ Client connecting to 11:11:11:11:11:11:11:11, TCP port 5001 TCP window size: 16.0 KByte (WARNING: requested 8.00 KByte) ------------------------------------------------------------ [ 3] local 11:11:11:11:11:11:11:22 port 32771 connected with 11:11:11:11:11:11:11:11 port 5001 [ 3] 0.0-4.0 sec 45.0 MBytes 92.6 Mbits/sec ------------------------------------------------------------ Client connecting to 11:11:11:11:11:11:11:11, TCP port 5001 TCP window size: 16.0 KByte (WARNING: requested 8.00 KByte) ------------------------------------------------------------ [ 3] local 11:11:11:11:11:11:11:22 port 32772 connected with 11:11:11:11:11:11:11:11 port 5001 [ 3] 0.0-4.5 sec 50.0 MBytes 92.6 Mbits/sec ------------------------------------------------------------ Client connecting to 11:11:11:11:11:11:11:11, TCP port 5001 TCP window size: 16.0 KByte (WARNING: requested 8.00 KByte) ------------------------------------------------------------ [ 3] local 11:11:11:11:11:11:11:22 port 32773 connected with 11:11:11:11:11:11:11:11 port 5001 [ 3] 0.0-4.9 sec 55.0 MBytes 92.6 Mbits/sec ------------------------------------------------------------ Client connecting to 11:11:11:11:11:11:11:11, TCP port 5001 TCP window size: 16.0 KByte (WARNING: requested 8.00 KByte) ------------------------------------------------------------ [ 3] local 11:11:11:11:11:11:11:22 port 32774 connected with 11:11:11:11:11:11:11:11 port 5001 [ 3] 0.0-5.4 sec 60.0 MBytes 92.6 Mbits/sec 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 5008 bytes from 11:11:11:11:11:11:11:11: icmp_seq=1 ttl=64 time=1.04 ms 5008 bytes from 11:11:11:11:11:11:11:11: icmp_seq=2 ttl=64 time=1.04 ms 5008 bytes from 11:11:11:11:11:11:11:11: icmp_seq=3 ttl=64 time=1.03 ms 5008 bytes from 11:11:11:11:11:11:11:11: icmp_seq=4 ttl=64 time=1.04 ms 5008 bytes from 11:11:11:11:11:11:11:11: icmp_seq=5 ttl=64 time=1.03 ms 5008 bytes from 11:11:11:11:11:11:11:11: icmp_seq=6 ttl=64 time=1.03 ms 5008 bytes from 11:11:11:11:11:11:11:11: icmp_seq=7 ttl=64 time=1.01 ms 5008 bytes from 11:11:11:11:11:11:11:11: icmp_seq=8 ttl=64 time=1.01 ms 5008 bytes from 11:11:11:11:11:11:11:11: icmp_seq=9 ttl=64 time=1.05 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 10008 bytes from 11:11:11:11:11:11:11:11: icmp_seq=0 ttl=64 time=1.98 ms 10008 bytes from 11:11:11:11:11:11:11:11: icmp_seq=1 ttl=64 time=1.99 ms
108
10008 bytes from 11:11:11:11:11:11:11:11: icmp_seq=2 ttl=64 time=1.88 ms 10008 bytes from 11:11:11:11:11:11:11:11: icmp_seq=3 ttl=64 time=1.96 ms 10008 bytes from 11:11:11:11:11:11:11:11: icmp_seq=4 ttl=64 time=1.88 ms 10008 bytes from 11:11:11:11:11:11:11:11: icmp_seq=5 ttl=64 time=1.99 ms 10008 bytes from 11:11:11:11:11:11:11:11: icmp_seq=6 ttl=64 time=1.88 ms 10008 bytes from 11:11:11:11:11:11:11:11: icmp_seq=7 ttl=64 time=1.96 ms 10008 bytes from 11:11:11:11:11:11:11:11: icmp_seq=8 ttl=64 time=1.89 ms 10008 bytes from 11:11:11:11:11:11:11:11: icmp_seq=9 ttl=64 time=1.95 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.886/1.940/1.997/0.048 ms, pipe 2 PING 11:11:11:11:11:11:11:11(11:11:11:11:11:11:11:11) 15000 data bytes 15008 bytes from 11:11:11:11:11:11:11:11: icmp_seq=0 ttl=64 time=2.86 ms 15008 bytes from 11:11:11:11:11:11:11:11: icmp_seq=1 ttl=64 time=2.86 ms 15008 bytes from 11:11:11:11:11:11:11:11: icmp_seq=2 ttl=64 time=2.80 ms 15008 bytes from 11:11:11:11:11:11:11:11: icmp_seq=3 ttl=64 time=2.85 ms 15008 bytes from 11:11:11:11:11:11:11:11: icmp_seq=4 ttl=64 time=2.78 ms 15008 bytes from 11:11:11:11:11:11:11:11: icmp_seq=5 ttl=64 time=2.88 ms 15008 bytes from 11:11:11:11:11:11:11:11: icmp_seq=6 ttl=64 time=2.79 ms 15008 bytes from 11:11:11:11:11:11:11:11: icmp_seq=7 ttl=64 time=2.86 ms 15008 bytes from 11:11:11:11:11:11:11:11: icmp_seq=8 ttl=64 time=2.77 ms 15008 bytes from 11:11:11:11:11:11:11:11: icmp_seq=9 ttl=64 time=2.85 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 = 2.770/2.833/2.884/0.061 ms, pipe 2 PING 11:11:11:11:11:11:11:11(11:11:11:11:11:11:11:11) 10000 data bytes 10008 bytes from 11:11:11:11:11:11:11:11: icmp_seq=0 ttl=64 time=1.97 ms 10008 bytes from 11:11:11:11:11:11:11:11: icmp_seq=1 ttl=64 time=1.95 ms --- 11:11:11:11:11:11:11:11 ping statistics --- 2 packets transmitted, 2 received, 0% packet loss, time 1001ms rtt min/avg/max/mdev = 1.954/1.965/1.977/0.045 ms, pipe 2 PING 11:11:11:11:11:11:11:11(11:11:11:11:11:11:11:11) 20000 data bytes 20008 bytes from 11:11:11:11:11:11:11:11: icmp_seq=0 ttl=64 time=3.77 ms 20008 bytes from 11:11:11:11:11:11:11:11: icmp_seq=1 ttl=64 time=3.74 ms 20008 bytes from 11:11:11:11:11:11:11:11: icmp_seq=2 ttl=64 time=3.73 ms 20008 bytes from 11:11:11:11:11:11:11:11: icmp_seq=3 ttl=64 time=3.70 ms 20008 bytes from 11:11:11:11:11:11:11:11: icmp_seq=4 ttl=64 time=3.70 ms 20008 bytes from 11:11:11:11:11:11:11:11: icmp_seq=5 ttl=64 time=3.76 ms 20008 bytes from 11:11:11:11:11:11:11:11: icmp_seq=6 ttl=64 time=3.73 ms 20008 bytes from 11:11:11:11:11:11:11:11: icmp_seq=7 ttl=64 time=3.72 ms 20008 bytes from 11:11:11:11:11:11:11:11: icmp_seq=8 ttl=64 time=3.71 ms 20008 bytes from 11:11:11:11:11:11:11:11: icmp_seq=9 ttl=64 time=3.72 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 = 3.707/3.734/3.779/0.021 ms, pipe 2 PING 11:11:11:11:11:11:11:11(11:11:11:11:11:11:11:11) 25000 data bytes
109
25008 bytes from 11:11:11:11:11:11:11:11: icmp_seq=0 ttl=64 time=4.69 ms 25008 bytes from 11:11:11:11:11:11:11:11: icmp_seq=1 ttl=64 time=4.59 ms 25008 bytes from 11:11:11:11:11:11:11:11: icmp_seq=2 ttl=64 time=4.67 ms 25008 bytes from 11:11:11:11:11:11:11:11: icmp_seq=3 ttl=64 time=4.54 ms 25008 bytes from 11:11:11:11:11:11:11:11: icmp_seq=4 ttl=64 time=4.69 ms 25008 bytes from 11:11:11:11:11:11:11:11: icmp_seq=5 ttl=64 time=4.57 ms 25008 bytes from 11:11:11:11:11:11:11:11: icmp_seq=6 ttl=64 time=4.65 ms 25008 bytes from 11:11:11:11:11:11:11:11: icmp_seq=7 ttl=64 time=4.64 ms 25008 bytes from 11:11:11:11:11:11:11:11: icmp_seq=8 ttl=64 time=4.66 ms 25008 bytes from 11:11:11:11:11:11:11:11: icmp_seq=9 ttl=64 time=4.56 ms --- 11:11:11:11:11:11:11:11 ping statistics --- 10 packets transmitted, 10 received, 0% packet loss, time 9008ms rtt min/avg/max/mdev = 4.549/4.630/4.697/0.067 ms, pipe 2 PING 11:11:11:11:11:11:11:11(11:11:11:11:11:11:11:11) 30000 data bytes 30008 bytes from 11:11:11:11:11:11:11:11: icmp_seq=0 ttl=64 time=5.60 ms 30008 bytes from 11:11:11:11:11:11:11:11: icmp_seq=1 ttl=64 time=5.52 ms 30008 bytes from 11:11:11:11:11:11:11:11: icmp_seq=2 ttl=64 time=5.59 ms 30008 bytes from 11:11:11:11:11:11:11:11: icmp_seq=3 ttl=64 time=5.51 ms 30008 bytes from 11:11:11:11:11:11:11:11: icmp_seq=4 ttl=64 time=5.56 ms 30008 bytes from 11:11:11:11:11:11:11:11: icmp_seq=5 ttl=64 time=5.51 ms 30008 bytes from 11:11:11:11:11:11:11:11: icmp_seq=6 ttl=64 time=5.56 ms 30008 bytes from 11:11:11:11:11:11:11:11: icmp_seq=7 ttl=64 time=5.57 ms 30008 bytes from 11:11:11:11:11:11:11:11: icmp_seq=8 ttl=64 time=5.50 ms 30008 bytes from 11:11:11:11:11:11:11:11: icmp_seq=9 ttl=64 time=5.50 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 = 5.500/5.545/5.600/0.049 ms, pipe 2 PING 11:11:11:11:11:11:11:11(11:11:11:11:11:11:11:11) 35000 data bytes 35008 bytes from 11:11:11:11:11:11:11:11: icmp_seq=0 ttl=64 time=6.50 ms 35008 bytes from 11:11:11:11:11:11:11:11: icmp_seq=1 ttl=64 time=6.46 ms 35008 bytes from 11:11:11:11:11:11:11:11: icmp_seq=2 ttl=64 time=6.39 ms 35008 bytes from 11:11:11:11:11:11:11:11: icmp_seq=3 ttl=64 time=6.53 ms 35008 bytes from 11:11:11:11:11:11:11:11: icmp_seq=4 ttl=64 time=6.41 ms 35008 bytes from 11:11:11:11:11:11:11:11: icmp_seq=5 ttl=64 time=6.47 ms 35008 bytes from 11:11:11:11:11:11:11:11: icmp_seq=6 ttl=64 time=6.41 ms 35008 bytes from 11:11:11:11:11:11:11:11: icmp_seq=7 ttl=64 time=6.44 ms 35008 bytes from 11:11:11:11:11:11:11:11: icmp_seq=8 ttl=64 time=6.49 ms 35008 bytes from 11:11:11:11:11:11:11:11: icmp_seq=9 ttl=64 time=6.43 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 = 6.399/6.458/6.533/0.055 ms, pipe 2 PING 11:11:11:11:11:11:11:11(11:11:11:11:11:11:11:11) 40000 data bytes 40008 bytes from 11:11:11:11:11:11:11:11: icmp_seq=0 ttl=64 time=7.36 ms 40008 bytes from 11:11:11:11:11:11:11:11: icmp_seq=1 ttl=64 time=7.34 ms 40008 bytes from 11:11:11:11:11:11:11:11: icmp_seq=2 ttl=64 time=7.36 ms 40008 bytes from 11:11:11:11:11:11:11:11: icmp_seq=3 ttl=64 time=7.39 ms 40008 bytes from 11:11:11:11:11:11:11:11: icmp_seq=4 ttl=64 time=7.34 ms
110
40008 bytes from 11:11:11:11:11:11:11:11: icmp_seq=5 ttl=64 time=7.38 ms 40008 bytes from 11:11:11:11:11:11:11:11: icmp_seq=6 ttl=64 time=7.36 ms 40008 bytes from 11:11:11:11:11:11:11:11: icmp_seq=7 ttl=64 time=7.33 ms 40008 bytes from 11:11:11:11:11:11:11:11: icmp_seq=8 ttl=64 time=7.37 ms 40008 bytes from 11:11:11:11:11:11:11:11: icmp_seq=9 ttl=64 time=7.32 ms --- 11:11:11:11:11:11:11:11 ping statistics --- 10 packets transmitted, 10 received, 0% packet loss, time 9008ms rtt min/avg/max/mdev = 7.328/7.360/7.399/0.110 ms, pipe 2 PING 11:11:11:11:11:11:11:11(11:11:11:11:11:11:11:11) 45000 data bytes 45008 bytes from 11:11:11:11:11:11:11:11: icmp_seq=0 ttl=64 time=8.31 ms 45008 bytes from 11:11:11:11:11:11:11:11: icmp_seq=1 ttl=64 time=8.29 ms 45008 bytes from 11:11:11:11:11:11:11:11: icmp_seq=2 ttl=64 time=8.26 ms 45008 bytes from 11:11:11:11:11:11:11:11: icmp_seq=3 ttl=64 time=8.32 ms 45008 bytes from 11:11:11:11:11:11:11:11: icmp_seq=4 ttl=64 time=8.29 ms 45008 bytes from 11:11:11:11:11:11:11:11: icmp_seq=5 ttl=64 time=8.28 ms 45008 bytes from 11:11:11:11:11:11:11:11: icmp_seq=6 ttl=64 time=8.24 ms 45008 bytes from 11:11:11:11:11:11:11:11: icmp_seq=7 ttl=64 time=8.28 ms 45008 bytes from 11:11:11:11:11:11:11:11: icmp_seq=8 ttl=64 time=8.35 ms 45008 bytes from 11:11:11:11:11:11:11:11: icmp_seq=9 ttl=64 time=8.27 ms --- 11:11:11:11:11:11:11:11 ping statistics --- 10 packets transmitted, 10 received, 0% packet loss, time 9008ms rtt min/avg/max/mdev = 8.247/8.294/8.356/0.076 ms, pipe 2 PING 11:11:11:11:11:11:11:11(11:11:11:11:11:11:11:11) 50000 data bytes 50008 bytes from 11:11:11:11:11:11:11:11: icmp_seq=0 ttl=64 time=9.21 ms 50008 bytes from 11:11:11:11:11:11:11:11: icmp_seq=1 ttl=64 time=9.22 ms 50008 bytes from 11:11:11:11:11:11:11:11: icmp_seq=2 ttl=64 time=9.06 ms 50008 bytes from 11:11:11:11:11:11:11:11: icmp_seq=3 ttl=64 time=9.24 ms 50008 bytes from 11:11:11:11:11:11:11:11: icmp_seq=4 ttl=64 time=9.10 ms 50008 bytes from 11:11:11:11:11:11:11:11: icmp_seq=5 ttl=64 time=9.25 ms 50008 bytes from 11:11:11:11:11:11:11:11: icmp_seq=6 ttl=64 time=9.10 ms 50008 bytes from 11:11:11:11:11:11:11:11: icmp_seq=7 ttl=64 time=9.22 ms 50008 bytes from 11:11:11:11:11:11:11:11: icmp_seq=8 ttl=64 time=9.18 ms 50008 bytes from 11:11:11:11:11:11:11:11: icmp_seq=9 ttl=64 time=9.24 ms --- 11:11:11:11:11:11:11:11 ping statistics --- 10 packets transmitted, 10 received, 0% packet loss, time 9008ms rtt min/avg/max/mdev = 9.060/9.187/9.256/0.078 ms, pipe 2 PING 11:11:11:11:11:11:11:11(11:11:11:11:11:11:11:11) 55000 data bytes 55008 bytes from 11:11:11:11:11:11:11:11: icmp_seq=0 ttl=64 time=10.1 ms 55008 bytes from 11:11:11:11:11:11:11:11: icmp_seq=1 ttl=64 time=10.1 ms 55008 bytes from 11:11:11:11:11:11:11:11: icmp_seq=2 ttl=64 time=10.0 ms 55008 bytes from 11:11:11:11:11:11:11:11: icmp_seq=3 ttl=64 time=10.1 ms 55008 bytes from 11:11:11:11:11:11:11:11: icmp_seq=4 ttl=64 time=10.1 ms 55008 bytes from 11:11:11:11:11:11:11:11: icmp_seq=5 ttl=64 time=10.2 ms 55008 bytes from 11:11:11:11:11:11:11:11: icmp_seq=6 ttl=64 time=10.0 ms 55008 bytes from 11:11:11:11:11:11:11:11: icmp_seq=7 ttl=64 time=10.1 ms 55008 bytes from 11:11:11:11:11:11:11:11: icmp_seq=8 ttl=64 time=10.0 ms 55008 bytes from 11:11:11:11:11:11:11:11: icmp_seq=9 ttl=64 time=10.1 ms
111
--- 11:11:11:11:11:11:11:11 ping statistics --- 10 packets transmitted, 10 received, 0% packet loss, time 9008ms rtt min/avg/max/mdev = 10.028/10.132/10.210/0.089 ms, pipe 2 PING 11:11:11:11:11:11:11:11(11:11:11:11:11:11:11:11) 60000 data bytes 60008 bytes from 11:11:11:11:11:11:11:11: icmp_seq=0 ttl=64 time=11.0 ms 60008 bytes from 11:11:11:11:11:11:11:11: icmp_seq=1 ttl=64 time=11.0 ms 60008 bytes from 11:11:11:11:11:11:11:11: icmp_seq=2 ttl=64 time=10.9 ms 60008 bytes from 11:11:11:11:11:11:11:11: icmp_seq=3 ttl=64 time=11.0 ms 60008 bytes from 11:11:11:11:11:11:11:11: icmp_seq=4 ttl=64 time=11.0 ms 60008 bytes from 11:11:11:11:11:11:11:11: icmp_seq=5 ttl=64 time=11.0 ms 60008 bytes from 11:11:11:11:11:11:11:11: icmp_seq=6 ttl=64 time=11.0 ms 60008 bytes from 11:11:11:11:11:11:11:11: icmp_seq=7 ttl=64 time=10.9 ms 60008 bytes from 11:11:11:11:11:11:11:11: icmp_seq=8 ttl=64 time=10.9 ms 60008 bytes from 11:11:11:11:11:11:11:11: icmp_seq=9 ttl=64 time=11.0 ms --- 11:11:11:11:11:11:11:11 ping statistics --- 10 packets transmitted, 10 received, 0% packet loss, time 9008ms rtt min/avg/max/mdev = 10.938/11.033/11.094/0.048 ms, pipe 2
112
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
113
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
114
7. Researcher is starting test
8. Researcher is observing test results
9. Researcher is capturing test results