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.2 Round Trip Time ……………………………………… 51

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


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


with data size ranging from 5.12 to 61.44 MB………..……………….. 47

4.4 Bandwidth Utilization Results for IPv4/IPv6 under Linux

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


with data size ranging from 5.12 to 61.44 MB……………….................. 48

4.6 Bandwidth Utilization Results for IPv4 under Linux and

Windows with data size ranging from 128 KB to 1.408 MB…..……….. 48


Windows with data size ranging from 128 KB to 1.408 MB…..………. 49

4.8 Bandwidth Utilization Results for IPv4 under Linux

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


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

4.10 Bandwidth Utilization Results for IPv4/IPv6 under Linux and

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


with data size ranging from 128 KB to 1.408 MB……………………… 51

4.12 Round Trip Time Results for IPv4/IPv6 under Windows with data

size ranging from 5.12 to 61.44 MB…………………………………………. 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


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


with data size ranging from 5.12 to 61.44 MB……………………….… 54


with data size ranging from 128KB to 1.408 MB……..…………… 55


with data size ranging from 5.12 to 61.44 MB……………..…….……… 55

4.20 Bandwidth Utilization Results for IPv4/IPv6 under Linux and

Windows with data size ranging from 5.12 to 61.44 MB………............. 56


with data size ranging from 128KB to 1.408 MB…………….………… 56

4.22 Round Trip Time Results for IPv4/IPv6 under Windows

with data Size ranging from 5.12 to 61.44 MB…..…………….……….. 57

4.23 Round Trip Time Results for IPv4/IPv6 under Linux

with data Size ranging from 5.12 to 61.44 MB……………..…………… 57

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


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.


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)


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)


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.


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)


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.


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)


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.


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)


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


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)


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)


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



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.


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)


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.


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)


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.


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)


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.


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)


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


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)


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)


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/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


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


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)


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)


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)



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


104


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

10.1.1.133.4437.pdf

Documents

performance of ipv4

router architectures

ipv6 protocols

ipv6 implementations

windows platforms

linux platforms

performance analysis

linux operating platforms