PERFORMANCE EVALUATION OF IPv4, IPv6, 6to4 TUNNELLING

AND DUAL STACK NETWORKS USING OPNET MODELER

TABLE OF CONTENTS
Contents
TABLE OF CONTENTS..................................................................................................................................... 2
CHAPTER ONE ............................................................................................................................................... 5
INTRODUCTION ......................................................................................................................................... 5
1.1

Background of Study ..................................................................................................................... 5

1.2

IP Addressing and Routing ............................................................................................................ 6

1.2.1

Historical Development of Internet Protocol version 4 (IPv4) .............................................. 7

1.2.2

Historical Development of Internet Protocol version 6 (IPv6) .............................................. 9

1.2.3

Internet Corporation for Assigned Name and Numbers (ICANN) ....................................... 10

1.3

Statement of Problem ................................................................................................................. 11

1.4

Research Objectives .................................................................................................................... 12

1.5

Research Questions .................................................................................................................... 12

1.6

Research Hypothesis ................................................................................................................... 13

1.7

Significance of Study ................................................................................................................... 14

1.8

Scope and Limitations of Study ................................................................................................... 14

1.9

Simulation with OPNET ............................................................................................................... 14

CHAPTER TWO ............................................................................................................................................ 15

Literature Review .................................................................................................................................... 15
2.1

Comparison between IPv4 and IPv6 Packet Formats ................................................................. 15

2.1.1

IPv4 Packet and Field Descriptions ..................................................................................... 15

2.1.2

IPv6 Packet and Field Descriptions ..................................................................................... 19

2.2

Advantages of IPv6 over IPv4 ...................................................................................................... 22

2.2.1

Address Space ..................................................................................................................... 23

2.2.2

Multicasting ........................................................................................................................ 24

2.2.3

Address Autoconfiguration ................................................................................................. 24

2.2.4

Simplified Processing by Routers ........................................................................................ 24

2.2.5

Options Extensibility ........................................................................................................... 26

2.2.6

Mobility ............................................................................................................................... 26

2.2.7

Jumbograms ........................................................................................................................ 26

2.2.8

Privacy ................................................................................................................................. 26
2

2.2.9

Network-Layer Security....................................................................................................... 27

2.2.10

Improved Internet Control Message Protocol (ICMPv6) .................................................... 27

2.3

Business Drivers of IPv6 over IPv4 .............................................................................................. 28

2.3.1

Tuning in to the future ........................................................................................................ 28

2.3.2

Increased Reliance on IT ..................................................................................................... 28

2.3.3

Future growth and expansion plans ................................................................................... 28

2.3.4

Regulatory and Industry Compliance .................................................................................. 29

2.3.5

Cost Effectiveness ............................................................................................................... 29

2.3.6

Communication Portability ................................................................................................. 29

2.3.7

Fuelling the Economy through the Internet ....................................................................... 29

2.4

IPv4 to IPv6 Transition Mechanisms and Scenarios .................................................................... 30

2.4.1

Dual Stack (IPv6/IPv4 Nodes) .............................................................................................. 31

2.4.2

Translation .......................................................................................................................... 33

2.4.3

Tunnelling............................................................................................................................ 37

2.5

Summary of the Three Transition Mechanisms .......................................................................... 44

CHAPTER THREE .......................................................................................................................................... 45

METHODOLOGY ...................................................................................................................................... 45
3.1

The Network Model .................................................................................................................... 45

3.1.1

The Simple Network Model ................................................................................................ 45

3.1.2

The Campus Network Model .............................................................................................. 46

3.2

Performance Metrics Used in Computer Networks.................................................................... 50

3.3

OPNET Modeler ......................................................................................................................... 52

3.3.1

OPNET Editors ..................................................................................................................... 54

3.3.2

OPNET Programming .......................................................................................................... 62

3.4

The Project/Scenario Workflow in OPNET Modeler .................................................................. 64

CHAPTER FOUR ........................................................................................................................................... 67

SIMULATION RESULTS AND ANALYSIS .................................................................................................... 67
4.1

Campus Network Simulation of Networks with FTP Traffic Only ............................................... 67

4.1.1

Ethernet Delay Analysis of FTP Packets with no background traffic .................................. 68

4.1.2

Download Response Time Analysis of FTP Packets with no background traffic ................. 69

4.1.3

Throughput Analysis of FTP Packets with no background traffic ....................................... 70

4.1.4

Packet Latency Analysis of FTP Packets with no background traffic .................................. 71

4.1.5

Utilization Analysis of FTP Packets with no background traffic .......................................... 72

3

4.2

Campus Network Simulation of Networks with FTP, HTTP and Database traffic ....................... 73

4.2.1

Ethernet Delay Analysis of FTP Packets with background traffic........................................ 73

4.2.2

Download Response Time Analysis of FTP Packets with background traffic ...................... 74

4.2.3

TCP Delay Analysis of FTP packets with background traffic................................................ 75

4.2.4

Throughput Analysis of FTP Packets with background traffic............................................. 76

4.2.5

Packet Latency Analysis of FTP Packets with background traffic ....................................... 77

4.2.6

Utilization Analysis of FTP packets with background traffic ............................................... 78

4.3

Simple Network Simulation of Networks with Video Traffic Only .............................................. 79

4.3.1

Ethernet Delay Analysis of Video Traffic with no background traffic ................................. 79

4.3.2

Packet Delay Variation Analysis of Video Traffic with no background traffic..................... 80

4.3.3

Packet Endto-End Delay Analysis of Video Traffic only..................................................... 81

4.3.4

Throughput Analysis of Video Traffic with no background traffic ...................................... 82

4.3.5

Utilization Analysis of Video Traffic with no background traffic......................................... 83

4.4

Simple Network Simulation of Networks with Video, FTP and Database traffic ........................ 85

4.4.1

Ethernet Delay Analysis of Video Packets with background traffic .................................... 85

4.4.2

Packet Delay Variation Analysis of Video Packets with background traffic........................ 86

4.4.3 Packet Endto-End Delay Variation Analysis of Video Packets with background traffic .......... 87
4.4.4

Throughput Analysis of Video Traffic with background traffic ........................................... 88

4.4.5

Utilization Analysis of Video Traffic with background traffic .............................................. 89

CHAPTER ONE
INTRODUCTION
Communication is a necessity in all aspects of human endeavours be it social or professional. For
tasks to be accomplished, people need to work together to solve problems and create resources for
an institution. For easy sharing and access of information among users, the computers involved
must be interconnected.

1.1

Background of Study

The Internet Protocol (IP) is the principal communications protocol in the internet protocol suite
for relaying datagrams across network boundaries. Its routing function enables internetworking,
and essentially establishes the Internet.
In May 1974, the Institute of Electrical and Electronic Engineers (IEEE) published a paper entitled
A Protocol for Packet Network Intercommunication. The papers authors, Vint Cerf and Bob
Kahn, described an internetworking protocol for sharing resources using packet switching among
network nodes. A central control component of this model was the Transmission Control
Program that incorporated both connection-oriented links and datagram services between hosts.
The monolithic Transmission Control Program was later divided into a modular architecture
consisting of the Transmission Control Protocol (TCP) at the transport layer and the Internet
Protocol (IP) at the network layer. The model became known as the Department of Defence (DoD)
Internet Model and Internet Protocol Suite, and informally as TCP/IP. The term Internet is a
global system of interconnected computer networks (internetworks) that use the standard internet
protocol suite (TCP/IP) to link several billion devices worldwide [3]. The term protocol defines
the format and the order of messages exchanged between two or more communicating entities, as
5

well as the actions taken on the transmission and/or receipt of a message or other event [4]. During
the early stages of development, the IP was used only by the military and research universities, but
gradually, computers from companies and additional universities were added. Today, much of the
worlds population is becoming more connected to and reliant on the Internet.
Supporting the Internet are a host of protocols. The two most common protocols are the Internet
Protocol (IP) and the Transmission Control Protocol (TCP). These protocols are themselves
supported by a host of secondary protocols, which include the Internet Control Message protocol
(ICMP), User Datagram Protocol (UDP), Address Resolution Protocol (ARP), Dynamic Host
Configuration Protocol (DHCP), and Network Address Translation (NAT) [1].
The Internet Protocol is one of the elements that define the Internet. The dominant internetworking
protocol in the Internet Layer in use today is IPv4; the number 4 is the protocol version number
carried in every IP datagram. The successor to IPv4 is IPv6. Its most prominent modification from
version 4 is the addressing system. IPv4 uses 32-bit addresses while IPv6 uses 128-bit addresses.
IP versions o to 3 were experimental versions used between 1977 and 1979.

1.2

IP Addressing and Routing

The IP which is the primary protocol in the internet layer of the Internet protocol suite, has the task
of delivering packets from the source host to the destination host solely based on the IP addresses
in the packet headers. A source and a destination IP address are usually assigned within a packet
and forwarded into the network. When packets are sent to a host, which is not located within the
same network as the source host, networking devices such as routers are used to receive packets
from the source host and forward it one step closer to the location of the network where the
destination host resides [5].

The concept of forwarding packets arrived as a new idea to early research scientists. The telephone
network was a global network which did not use the concept of packet forwarding. Telephone
networks used a circuit switch implementation, consisting of a fixed circuit source and destination.
All the traffic was sent over this connection. With the advent of IP, packets do not travel along
established fixed circuits. The packets are addressed with a source and destination address; then
forwarded through the network [5].
The IP allows a packet to be forwarded through different networks in order to reach the destination.
These individual networks may define their own rules of sending data through their routing devices
with each network adhering to their respective rules. IP allows a packet to adapt to each of the
individual networks as it traverses. The size of the packet may vary from network to network. The
IP allows a packet to be fragmented and then reassembled at the destination [5].
Addressing and fragmentation are the two basic functions implemented by the IP. Network within
the Internet use included addresses within a data packet to transmit that data to its destinations.
The field option in the packet header contains information necessary to perform fragmentation and
reassembly of the data packet. This is useful in the transmission of a packet through small packet
networks [6].

1.2.1

Historical Development of Internet Protocol version 4 (IPv4)

IPv4 is the fourth version in the development of the Internet Protocol (IP), and routes most traffic
on the Internet. It is a connectionless protocol for use on packet-switched networks. It operates on
a best effort delivery model, in that it does not guarantee delivery, nor does it assure proper
sequencing or avoidance of duplicate delivery.

IPv4 was designed to be used when sending data across the network. Not only does this happen
but IP also provides, according to Postel (1981), fragmentation and reassembly of long
datagrams, if necessary, for transmission through "small packet" networks. Fragmentation and
reassembly is a very important feature of IP. Network devices such as network interface cards can
define the maximum unit that can be transferred. When this device receives an IP packet where
the payload is more than the defined Maximum Transmission Unit (MTU), the device will
fragment the data. Each segment must be equal to or less than the defined MTU. As a result, each
segment of the fragmented data will be flagged, and this way the receiving side can tell that this
data has more than one segment and is able to identify the segments. When the first packet arrives
at the receiving side, the device will see the flag and it can then tell that this packet is a part of a
fragment. The receiver will then store the packet until it receives them all.
IPv4 included an addressing system that used numerical identifiers consisting of 32-bits (four
bytes) address length, which limited the address space to approximately 4.3 billion (232) addresses.
As addresses were assigned to users, the number of unassigned addresses decreased. When IPv4
was written, it appeared to be a sufficient amount of IP addresses at that time. However, as time
progressed, the Internet grew with the advent of new networking devices such as phones, TVs,
tablets and gaming consoles, which were IP-capable. This led to the exhaustion of IPv4 address
space on February 3, 2011 [7]. According to Fletcher (2011), the Internet Address and Naming
Agency allocated the last blocks of internet addresses on Tuesday, with three out of the eight
remaining blocks going to the Asia Pacific region. Another report from the Xinhua News Agency
(2011) stated that, the pool of available unallocated addresses for the existing Internet protocol
has now been completely emptied, the organization that oversees the allocation of Internet
addresses announced on Thursday.

Four temporary solutions were found to overcome the exhaustion of IPv4 address space. The first
solution was Classless Inter-Domain Routing (CIDR) which is the method for allocating IP
addresses and routing IP packets. The goal here was to decrease the growth of routing tables within
the Internet in order to restrict the rapid exhaustion of IPv4 addresses. Frankel and Green (2008)
stated that, CIDR enables a variable-sized network prefix, allowing more flexibility in the number
of addresses included in allocated address blocks. The second solution was a technique termed
Network Address Translation (NAT) in which one IP address could be translated to multiple hosts
within the NAT network. Frankel and Green (2008) stated how NAT works, a NAT box, situated
between the private network and the Internet, manipulates portions of the header (most frequently,
the port number) so that it can distinguish which incoming traffic is intended for each device on
the network. The third solution is termed Dynamic Host Configuration Protocol (DHCP) which
is used on IP networks as the automatic configuration protocol. The fourth is called the classful
network design, which was used in the internet from 1981 until the introduction of CIDR in 1993.
This method divides the address space for IPv4 into five address classes. However, in CIDR, the
need for larger routing tables in routers became evident, which resulted in routing difficulties. The
NAT solution breaks the principle of the Internet and is not supported by some applications [8].
The classful network address scheme supported few individual networks and clearly could not
support the growing Internet. These four technologies were designed as solutions but made the
networks much slower and complex [7]. In addition, these four technologies did not overcome the
problem of IPv4 address exhaustion, but only delayed it.

1.2.2

Historical Development of Internet Protocol version 6 (IPv6)

IPv6 is the most recent version of the Internet Protocol (IP) and was deployed by the Internet
Engineering Task Force (IETF) to deal with the long-anticipated problem of IPv4 address
9

exhaustion. By 1998, the IETF had formalized the successor protocol, IPv6, which uses a 128-bit
address, allowing 2128, or approximately 3.4 1038 addresses, or more than 7.9 1028 times as
many as IPv4, which uses 32-bit address and provides approximately 4.3 billion addresses. With
the IPv6 128-bit address space, in U.S. measurements, Beijnum (2006) stated that, it's enough to
supply every square inch of the Earth's surface with the equivalent of a hundred trillion IPv4
Internets, thus providing a solution to IP address exhaustion.
IPv6 offers a significant improvement of IPv4 when it comes to the unlimited address space, the
built-in mobility and the security support, easy configuration of end systems, as well as enhanced
multicast features, etc. Chengqing, Yinglong and Jizhi (2007) stated that, IPv6 was designed not
only to increase the address space, but also includes unique benefits such as scalability, security,
simple routing capability, easier configuration plug and play, support for real-time data and
improved mobility support. [9].
Due to the practical difficulties in obtaining large blocks of new, unassigned IPv4 addresses,
major organizations in the fast-growing markets of Asia and Europe, as well as mobile service
providers worldwide are under increasing pressure to migrate from the entrenched IPv4 standard
to the emerging IPv6 one. As we continue to see increasing global scale deployments of IPv6
networks, there has also been an increasing interest in measuring the performance of these IPv6
networks [10]-[15].
In this thesis the IPv4 and IPv6 together with the transition from IPv4 to IPv6 will be studied.

1.2.3

Internet Corporation for Assigned Name and Numbers (ICANN)

ICANN controls the allocation of IP addresses and delegates a large portion of IP address space to
Regional Internet Registries (RIR). Each RIR then allocates the portion of IP address space
10

obtained from ICANN to the organizations operating in different geographical areas. This process
ensures that each address allotted to a host is unique. American Registry for Internet Numbers
(ARIN) controls IP address allocation within the United States. Internet Service Providers (ISPs),
universities and large corporations are a few of the organizations that apply to their respective RIR
for their geographical location in order to receive an IP address. This system promotes efficient
distribution of IP address space. This is significant since IP address space is a valuable resource,
illustrated by the high yearly fees paid for IP address blocks. RIR makes sure that the requesting
organization properly documents the necessary requirements to obtain IP address blocks simply
because they can afford it [5].
Grouping of similar IP addresses has a positive effect. This helps in efficient routing of packets
along the network. When IP addresses are assigned randomly, the router has to record each
individual location of an IP address. When large blocks of IP address are allocated to a particular
region, a router may only maintain a single route for the block [5].

1.3

Statement of Problem

Due to the exhaustion of IP address space and other limitations of IPv4, the development of IPv6
in the 1990s was stimulated, and has thus been in commercial deployment since 2006. Many
improvements which will be discussed in Chapter 2 were made on the IPv6 protocol. Thus the
network performance metrics of both IPv4 and IPv6 will be studied together with the feasibility of
implementation.
The two protocols are not designed to be interoperable, thus complicating the transition to IPv6.
However, several IPv6 transition mechanisms have been devised to permit communication
between IPv4 and IPv6 hosts. Whenever an IPv6 host wants to communicate with an IPv4 host, it

11

has to use tunnelling mechanisms where an IPv6 packet is encapsulated within an IPv4 packet.
These mechanisms will be discussed in Chapter two. Also the network performance metrics of
IPv4 and IPv6 will be compared to two other transition mechanisms manual and 6to4 tunnelling.

1.4

Research Objectives

The research objectives from this thesis work include:

Acquiring thorough understanding of IP as well as definitions, ideas, and arguments of

IPv6 transition methods.

Getting better understanding of the differences in network performance metrics between

IPv4, IPv6, 6to4 Tunnelling and Dual Stack networks and also the feasibility and cost of
the transition mechanisms.

Getting a good understanding of IPv6 address deployment and implementation in a

simulated environment.

Understanding and thus proposing the best method for transitions from IPv6 addresses to
IPv4 addresses for a campus network.

1.5

Introducing the simulation tool - OPNET Modeler.

Research Questions

The most important and also initial step of any research is to define the research question. Thus,
the research questions for this thesis are:

What are the main differences in network performance metrics between IPv4 and IPv6 in
a campus network environment?

What are the main reasons why it is important to transit from IPv4 to IPv6 in todays
network environment?
12

In transitioning from IPv4 to IPv6, what are the different transition mechanisms possible?

Which of the transition mechanisms is most cost effective, easily scalable and efficient and
what criteria is used to determine this?

1.6

Research Hypothesis

There are a number of aspects of network environment that toil together in order to send packets
successfully from source to destination. They include operating systems currently used in network
environments, protocols used for transporting packets from source to destination and different
packet sizes that are used in real network environments on both of the two internet protocols (IPv4
and IPv6). The hypothesis for this thesis work is divided into two main parts. The first part of the
hypothesis of this study is that:
The performance of networks implemented in real life and in a simulated environment gives
different performance metric values depending on the network protocol type and file size, and the
internet protocol version utilized (IPv4 or IPv6).
The second part of the hypothesis is that:
The network performance of networks is influenced by the type of transition mechanism from
IPv4 to IPv6 implemented.
There are also a number of hypotheses that will be tested in this study and these are as follows:
1. IPv4 and IPv6 networks have different MTUs and so give different network performance
values in real and simulated environments.
2. IPv4 and IPv6 networks implemented with varying FTP file sizes give different network
performance metrics in both real and simulated network environments.

13

3. IPv4 and IPv6 networks simulated with Voice over IP (VoIP) give different network
performance metrics.

1.7

Significance of Study

1.8

Scope and Limitations of Study

1.9

Simulation with OPNET

Simulation is becoming an increasingly popular method for network performance analysis.

Software simulator is a valuable tool especially for recent networks with complex architectures
and topologies. A typical simulator can provide the programmer with the necessary information
of how to control and manage the performance of a computer network. Functions and
protocols are described either by finite state machine, native programming code, or a
combination of the two [1]. Network simulators have developed since they first appeared
as performance, management and prediction tools. They are normally used as network
management tools, for which packet level analysis is not commonly employed. The most
known network simulator OPNET (OPNET stands for OPtimum NETwork performance) from
OPNET Technologies Inc. [2] is superior compared with other network simulation packages
in terms of user interface, flexibility, scalability, and accuracy [3,4]. OPNET Modeler will be
discussed in more detail in chapter three.

14

CHAPTER TWO
Literature Review
In this literature review, prior research and studies has been explored regarding the domain. This
chapter consists of a brief description of the two main internet protocols, which are IPv4 and IPv6.
This is important as it provides a logical understanding of why these two protocols are included in
this study. The problems and opportunities offered by these protocols are also presented.
Discussion and explanation of why the performance of a network is important to be monitored
at all times is also given. Later on in the chapter, some transition mechanisms used in todays
networks would be discussed.

2.1

Comparison between IPv4 and IPv6 Packet Formats

As mentioned earlier, the Internet Protocol (IP) provides a connectionless data transfer service
over heterogeneous networks by passing and routing IP datagrams. An IP datagram is basically
another name for a data packet. All IP datagrams or packets that are passed down from the transport
layer to the network layer (the connectionless packet delivery layer) are encapsulated with an IP
header that contains the information necessary to transmit the packet from one network to another.

2.1.1

IPv4 Packet and Field Descriptions

A key part of the IP service model is the type of packets that can be carried. The IP datagram, like
most packets, consists of a header followed by a number of bytes of data. The format of the header
is shown in Figure 2.1.
The version field specifies the version of IP and is 4 bits long. The current version of IP is 4, and
it is sometimes called IPv4. It can be seen that putting this field right at the start of the datagram

15

makes it easy for everything else in the packet format to be redefined in subsequent versions; thus
the header processing software starts off by looking at the version and then branches off to process
the rest of the packet according to the appropriate format.
The Header length (Hlen), specifies the length of the header in 32-bit words and is pointing to the
beginning of the word. When there are no options, which is most of the time, the header is 5 words
(20 bytes) long.
The Service Type field, which is also called Type of Service (TOS) specifies the type of service
desired and has an 8-bit length. It allows packets to be treated differently based on application
needs. It specifies the IP priority. Several networks have service precedence in which high
precedence traffic is considered more important. Sometimes during high load, routers accept traffic
above a defined precedence. Delay, throughput, and reliability are other parameters available to
define the precedence [6].

Figure 2.1: IPv4 Packet Header

16

The next 16 bits (Total Length field) of the header contains the Length of the datagram, including
the header. Unlike the HLen field, the Total Length field counts bytes rather than words. Thus, the
minimum length of an IP datagram is 20 bytes (20-byte header + 0 bytes data) and the maximum
size is 65,535 bytes (the maximum value of a 16-bit word). The physical network over which IP
is running, however, may not support such long packets. For this reason, IP supports a
fragmentation and reassembly process. Fragmentation is handled in either the host or router in
IPv4.
The Identification field has a 16-bit length. This aids in assembling the fragments of packets at
the destination [6]. Fragmentation typically occurs in a router when it receives a datagram that it
wants to forward over a network that has an MTU that is smaller than the received datagram. To
enable these fragments to be reassembled at the receiving host, they all carry the same identifier
in the identification field. This identifier is chosen by the sending host and is intended to be unique
among all the datagrams that might arrive at the destination from this source over some reasonable
period of time.
The Flags field has a 3-bit length. It is used to control and identify fragments. The first bit is
reserved and must be set to zero. The second bit specifies whether or not fragmentation is required.
A 0 value means fragmentation may be required otherwise a 1 value signifies no fragmentation
required. The third bit specifies whether or not this is the last fragment of the packet. If this bit is
0 then it is the last fragment, and if the bit is 1, then more fragments are to follow [6].
The Fragment offset field has a 13-bit length and is measured in units of 8-byte blocks (64 bits).
It specifies the offset of a particular fragment relative to the beginning of the original unfragmented
IP datagram. The first fragment has an offset of zero. This allows a maximum offset of (213 1)

17

8 = 65,528 bytes, which would exceed the maximum IP packet length of 65,535 bytes with the
header length included (65,528 + 20 = 65,548 bytes).
The 8-bit time to live (TTL) field helps prevent datagrams from persisting (e.g. going in circles)
on the Internet. It indicates the maximum time a packet is allowed to stay alive on the Internet. It
is specified in seconds, but time intervals less than 1 second are rounded up to 1. Whenever a
packet arrives at the router, this field value is decremented by 1. When the value becomes zero,
the packet is discarded by the router and sends an ICMP Time Exceeded message to the sender
[6].
The Protocol field defines the protocol used in the data portion of the IP datagram and the values,
which is defined in RFC 790, are maintained by the Internet Assigned Numbers Authority. It has
an 8-bit length [6].
The Header checksum is a 16-bit field and is used for error-checking of the header. When a packet
arrives at a router, the router calculates the checksum of the header and compares it to the
checksum filed. If the values do not match, the router discards the packet. Errors in the data field
must be handled by the encapsulated protocol.
The Source IP address is a 32-bit field and is the IPv4 address of the sender of the packet. This
address may be changed in transit by a network address translation device.
The Destination IP address is a 32-bit field and is the IPv4 address of the receiver of the packet.
As with the source address, this may be changed in transit by a network address translation device.
The Options field is variable in length. There may be zero or more options. This field is not
mandatory for every IP packet. It may be noted that the value in the Header Length field must
include enough extra 32-bit words to hold all the options (plus any padding needed to ensure that
18

the header contains an integer number of 32-bit words). The following are the possible options:
End of Options List (EOL), no operation, security, loose source routing, strict source routing,
record route, stream ID and Internet timestamp [6].
The Padding field like the options field is of variable length. It ensure the Header length ends on
a 32-bit boundary [6].
The Data portion of the packet is not included in the packet checksum. Its contents are interpreted
based on the value of the Protocol header field. Some common protocols for the Data portion
include: ICMP, IGMP, TCP, UDP, OSPF, SCTP etc.

2.1.2

IPv6 Packet and Field Descriptions

Despite the fact that IPv6 extends IPv4 in several ways, its header format is actually simpler. This
simplicity is due to a concerted effort to remove unnecessary functionality from the protocol. Thus
fields such as Identification, Header Length, Flag, Header checksum, Fragmentation Offset and
Total Length present in IPv4 have been removed.
The Version field has a 4-bit length and specifies the format of the header. It is set in binary format
with a constant value 6 (bit sequence 0110).
The Traffic Class has an 8-bit length and has replaced Type of Service in the IPv4 packet. It is
used by source nodes and routers on the path to the destination in order to distinguish between
different priority packets. General requirements that apply to the Traffic Class field are as follows.
Interface to IPv6 service must allow the upper layer protocol to provide the values to the Traffic
Class bits of a packet, which is originated at the upper layer protocol. Secondly, the nodes must be
permitted to change the traffic class bits.

19

Figure 2.2: IPv6 Packet Header

Nodes should ignore these traffic class bits if they have no specified use. Lastly, the value in the
Traffic Class Field should not be assumed unchanged by upper layers on the protocol stack when
the packet is received [12].
The Flow Label has a 20-bit length. This field is used by the source to label the sequence of packets
in order to get special handling from routers. The Flow label is checked at the router, values are
changed based on the next interface and then packets are forwarded. If routers do not support this
field, then it would just forward the packet and the field value is left unchanged. This saves
unnecessary delays such as routing table look up [13].
The Payload field gives the length of the packet, excluding the IPv6 header, measured in bytes. It
replaces the Total Length field in IPv4 and has a 16-bit length.

20

The NextHeader field cleverly replaces both the IP options and the Protocol field of IPv4. If
options are required, then they are carried in one or more special headers following the IP header,
and this is indicated by the value of the NextHeader field. It has an 8-bit length.
The Hop Limit is similar to the Time to Live field in the IPv4 header. It does perform the
calculation of the time interval. Whenever a packet passes through a node, the value in hop limit
is decreased by 1. When the value in this field is zero, the packet gets discarded. The size of this
field is 8-bits.
The Source Address field contains the address of the sender and has a 128-bit length.
The Destination Address field contains the address of the receiver and has a 128-bit length.
Table 2.1 below summarizes the differences between IPv4 and IPv6 Header Formats

21

Table 2.1: Summary of Comparison between IPv4 and IPv6

2.2

Advantages of IPv6 over IPv4

One of the reasons the Internet has been successful is the ability to interoperate with a variety of
technologies and communication lines. When two devices communicate, it is highly unlikely that
they are communicating directly with one another. In the majority of cases, there are many devices
in between the two systems trying to communicate. These intermediary devices are the brains of
what transitions the communications from one technology to another. IPv6 has been inundated
with a wide variety of features. It specifies a new packet format, designed to minimize packet
header processing by routers. Because the headers of IPv4 packets and IPv6 packet are
significantly different, the two protocols are not interoperable. However, in most respects, IPv6 is
an extension of IPv4. Most transport and application-layer protocols need little or no change to
operate over IPv6; exceptions are application protocols that embed Internet-layer addresses, such
as FTP and NTP, where the new address format may cause conflicts with existing protocol syntax
[14].

22

2.2.1

Address Space

The main advantage of IPv6 over IPv4 is its larger address space. The 128 bit address space of
IPv6

is

beyond

anyones

imagination.

According

to

Beijnum

(2006)

it

is,

340,282,366,920,938,463,463,374,607,431,768,211,456 for IPv6 while there is only

4,294,967,296 possible addresses for IPv4. Thus, the increase in the address length from 32-bit
to 128-bit resulted in a large quantity of available addresses. Even if a single individual utilizes
thousands of IP capable devices, the IP addresses would not get exhausted. With the increase in
the quantity of IP addresses the requirement for NAT was eliminated. Availability of IP addresses
resulted in a more efficient assignment of addresses to the networks as well as a more simplistic
routing procedure. The routing tables in IPv6 have fewer entries compared to Ipv4, thereby
enabling quick look-ups. With the increase in the number of IP addresses more peer-to-peer
applications were designed with improved speed and reliability [15].
Renumbering an existing network for a new connectivity provider with different routing prefixes
is a major effort with IPv4 [16]. With IPv6, however, changing the prefix announced by a few
routers can in principle renumber an entire network, since the host identifiers (the least-significant
64 bits of an address) can be independently self-configured by a host [16].

Table 2.2: IPv4 and IPv6 Address Space

23

2.2.2

Multicasting

Multicasting, which is the transmission of a packet to multiple destinations in a single send

operation, is part of the base specification in IPv6. In IPv4, this is an optional although commonly
implemented feature [17]. Ipv6 multicast addressing shares common features and protocols with
IPv4 multicast, but also provides changes and improvements by eliminating the need for certain
protocols.

2.2.3

Address Auto-configuration

Dynamic Host Configuration Protocol (DHCP) is used to obtain IPv4 addresses and the domain
name server. DHCPv6 was published for IPv6. The most important feature of IPv6 is to
automatically configure itself. The Neighbour Discovery feature in IPv6 enables the hosts to know
the availability of routers on the network, whereas in IPv4, hosts must wait until a router advertises
its address. In IPv6 the host broadcasts the router solicitation message and waits for a response
from a router indicating its presence. Through the router solicitation message a host gets the
network prefix from a router on the local network. The host then uses the network prefix with its
MAC address to know its IP address. This procedure enables a host to keep the IP addresses the
same while changing networks [18] [19].

2.2.4
(i)

Simplified Processing by Routers

Simplified Header

IETF designed a simplified header format for IPv6. This header was stripped of nonessential fields
that were available in IPv4. This format increased the performance and efficiency at the nodes.
The Header length field of IPv4 was removed. Likewise Total length is replaced by Payload
Length, which refers to the size of the payload after header.
24

(ii)

No Fragmentation

Further fields removed are Fragmentation Offset and Flag, since IPv6 packets do not undergo
fragmentation. IPv6 hosts are required to either perform path MTU discovery, perform end-to-end
fragmentation, or to send packets no larger than the IPv6 default MTU size of 1280 octets [20].
(iii)

Hop Limit

The Time to Live (TTL) field of IPv4 was replaced by Hop Limit in IPv6. This reflects the fact
that routers are no longer expected to computer the time a packet has spent in a queue [20].
(iv)

IP Checksum

The IPv6 header is not protected by a checksum; integrity protection is assumed to be assured by
both link-layer and higher-layer (TCP, UDP, etc.) error detection. UDP/IPv4 may actually have a
checksum of 0, indicating no checksum; IPv6 requires UDP to have its own checksum. Therefore,
IPv6 routers do not need to recompute a checksum when header fields (such as the time to live
(TTL) or hop count) change [20].
(v)

Flow Label

This is one of the fields present in the IPv6 header, which indicates the routers that will handle the
packets traveling from sources to destination in a special manner. The flow on the network is
identified by Flow Label and the source address of the packet. Specific flow indicates that the
packets originated from the same source. The packets originating from the same sources belonging
to a flow will have the same kind of requirement. The requirements of the packets are decided
before they are transmitted onto the network. Once it is on the network, routers check the flow
label to identify the special handling requirements of the packet. Packets belonging to the same

25

flow will have the source, destination address and routing options. This enables the router to
process at a faster rate [7].

2.2.5

Options Extensibility

The IPv6 packet header has a fixed size (40 octets). Options are implemented as additional
extension headers after the IPv6 header, which limits their size only by the size of an entire packet.
The extension header mechanism makes the protocol extensible in that it allows future services for
quality of service, security, mobility, and others to be added without redesign of the basic protocol
[21].

2.2.6

Mobility

Unlike mobile IPv4, mobile IPv6 avoids triangular routing and is therefore as efficient as native
IPv6. IPv6 routers may also allow entire subnets to move to a new router connection point without
renumbering.

2.2.7

Jumbograms

Jumbogram is an internet layer packet exceeding the standard maximum transmission unit (MTU)
of the underlying network technology. IPv4 limits packets to 65,535 (216 1) octets of payload.
An IPv6 node can optionally handle packets over this limit, referred to as jumbograms, which can
be as large as 4,294,967,295 (232-1) octets. The use of jumbograms may improve performance
over high-MTU links. The use of jumbograms is indicated by the Jumbo Payload Option header
[22].

2.2.8

Privacy

Like IPv4, IPv6 supports globally unique IP addresses by which the network activity of each device
can potentially be tracked. The design of IPv6 intended to re-emphasize the end-to-end principle
26

of network design that was originally conceived during the establishment of the early Internet. In
this approach each device on the network has a unique address globally reachable directly from
any other location on the Internet.
(i)

Network Prefix

Network prefix tracking is less of a concern if the users ISP assigns a dynamic network prefix via
DHCP. [23]. Privacy extensions do little to protect the user from tracking if the ISP assigns a static
network prefix. In this scenario, the network prefix is the unique identifier for tracking and the
interface identifier is secondary.
(ii)

Interface Identifier

In IPv4 the effort to conserve address space with network address translation (NAT) obfuscated
network address spaces, hosts, and topologies. In IPv6 when using address auto-configuration, the
Interface Identifier (MAC address) of an interface port is used to make its public IP address unique,
exposing the type of hardware used and providing a unique handle for a users online activity.

2.2.9

Network-Layer Security

Internet Protocol Security (IPSec) was originally developed for IPv6, but found widespread
deployment first in IPv4, for which it was re-engineered. IPsec was a mandatory specification of
the base Ipv6 protocol suite, but has since been made optional [24].

2.2.10 Improved Internet Control Message Protocol (ICMPv6)

Provides neighbour discovery and auto-configuration. By integrating with Internet Protocol
Security (IPSec) protects fear of ICMP based attacks.

27

2.3

Business Drivers of IPv6 over IPv4

Sooner than later, organizations will have to adopt IPv6. In addition to the dissipation of IPv4
addresses, there are some interesting business drivers that are driving organizations to quickly plan
for transition to IPv6. Some of such drivers are as follows:

2.3.1

Tuning in to the future

Ipv6 is the future of the Internet and IT services especially emerging ones like cloud computing,
SaaS, peer-to-peer applications, mobile computing etc. the vast pool of IPv6 addresses along with
enhanced features that come with it mean that we are yet to see the best of the Internet.

2.3.2

Increased Reliance on IT

When Internet was first invented, the requirements of data traffic did not require the device to be
a uniquely addressable entity. However, in this age of broadband and 4G networks where anything
and everything is designed to run on the Internet, the network devices on wired or wireless
networks need dedicated public facing IP addresses.

2.3.3

Future growth and expansion plans

Many organizations seem to have purchased a pool of enough IPv4 addresses to support their
existing plans and mitigate any risks associated with IPv4 exhaustion; such pool may not do justice
to unexpected opportunities of rapid growth. Furthermore, organizations willing to roll-out new
services on large scale may end up acquiring IPv6 addresses because large blocks of IPv4
addresses are no more available.

28

2.3.4

Regulatory and Industry Compliance

More and more Governments today are considering bringing in regulations to make IPv6
deployments mandatory in the platforms and applications pertaining to e-governance. Being IPv6
ready to qualify as a supplier of IT services or products could become a de-facto standard soon.

2.3.5

Cost Effectiveness

The cost of a planned transition vis--vis a forced one (either due to business reasons or regulatory
ones) is comparably less. In addition, starting early will also give network administrators and
managers an opportunity to gain experience on handling dual set of protocols and eventually help
in getting ready to support IPv6 networks.

2.3.6

Communication Portability

The need for businesses to communicate to their existing and potential customers is not just limited
to traditional computing devices such as PCs and laptops. Mobile devices are increasingly being
used as computing devices of choice and given that they are IPv6 compatible, organizations need
to upgrade to IPv6 to communicate with these devices.

2.3.7

Fuelling the Economy through the Internet

According to some estimates, IPv4 address allocation amongst countries is as follows: US-37%,
UK-11%, China-7%, Japan-7%, India-0.7% etc. It can be argued that the growth of some of these
economies are not only going to propel the growth of the Internet but will act as an engine of
growth for the economies. IPv6 will ensure there is no hindrance to economic growth of the
countries and world economy as well.

29

2.4

IPv4 to IPv6 Transition Mechanisms and Scenarios

Ipv6 transition mechanisms are technologies that facilitate the transitioning of the Internet from its
initial (and current) IPv4 infrastructure to the successor addressing and routing system of IPv6. As
IPv4 and IPv6 networks are not directly interoperable, these technologies are designed to permit
hosts on either network to participate in networking with the other network.
To meet its technical criteria, IPv6 must have a straightforward transition plan from the current
IPv4 [26]. The IETF conducts working groups and discussions through the IETF Internet Drafts
and Requests for Comments processes to develop these transition technologies towards that goal.
Any transition strategy entails finding ways to support IPv6 addresses for adding new customers
and/or new devices while continuing to support existing IPv4 addresses. Since IPv6 is not
backward compatible with IPv4, routers running IPv6 must have different routing tables in order
to serve IPv4-addressed devices, provisions for security must be altered, and many other steps
must be taken to allow an IPv6-based ecosystem to emerge in an IPv4-saturated environment [27].
Since the migration from IPv4 to Ipv6 is still a long-term goal for many organizations, equal
consideration has been given to the interim coexistence of IPv4 and IPv6 nodes. There are different
types of nodes that exist in the network such as IPv4-only, IPv6-only, IPv6/IPv4 nodes, Ipv4 nodes
and IPv6 nodes. There are different types of compatibility addresses such as IPv4-compatible
address, IPv4-mapped addresses, 6over4 addresses, 6to4 address, ISATAP addresses, Teredo
addresses etc. To coexist with an IPv4 infrastructure and to provide an eventual transition to an
IPv6-only infrastructure, the following mechanisms could be adopted [28].

30

2.4.1

Dual Stack (IPv6/IPv4 Nodes)

Figure 2.3: Dual IP Stack Architecture

From Figure 2.3 above, the dual stack happens in the network layer, which contains both IPv4 and
IPv6. Stack means, A stack is a type of data structure -- a means of storing information in a
computer. When a new object is entered in a stack, it is placed on top of all the previously entered
objects. In other words, the stack data structure is just like a stack of cards, papers, credit card
mailings, or any other real-world objects you can think of. The term "stack" can also be short for
a network protocol stack. In networking, connections between computers are made through a series
of smaller connections. These connections, or layers, act like the stack data structure, in that they
are built and disposed of in the same way [29].
The baseline migration strategy is Dual Stack, where the service provider runs both IPv4 and IPv6
over the network, allowing end user devices to communicate in whichever protocol theyre
equipped for [30]. The dual stack method can be achieved in both end systems and network
devices. As a result, IPv4 enabled programs use IPv4 stack and this goes the same for IPv6. The
IP header version field would play an important role in receiving and sending packets. In other
words, this kind of IPv6 transition is the encapsulation of IPv6 within IPv4. The complete

31

transition can be managed by DNS, for example, in the circumstance that a dual-stacked device
queries the name of a destination and DNS gives it an IPv4 address (a DNS A Record), it sends
IPv4 packets, or in case DNS responds with an IPv6 address (a DNS AAAA Record), it sends IPv6
packets. This mechanism is currently the best choice for the transition as many operating systems
have applied dual IP protocol stacks [31].

Figure 2.4: The structure of Dual Stack Model

Figure 2.4 above shows that the dual stack mechanism is implemented in the network layer for
both IPv4 and IPv6. Before transferring the packet to the next layer, the network layer will choose
which one to use based on the information from the datalink layer. Large enterprise networks that
have decided to transit to IPv6 can apply the dual stack method as the basic strategy, which
involves the device configuration to be able to utilize IPv4 and IPv6 at the same time on the core
routers, perimeter routers, firewalls, server-farm routers, and desktop access routers. Depending
on the response to DNS requests, applications can choose which protocol to use and this choice
can be made in consonance with the type of IP traffic. Furthermore, hosts can attain both available
IPv4 content and IPv6 content [31]. Accordingly, dual stack mechanism presents a flexible
transition strategy. However, despite its greatest flexibility, there are still some concerned issues
32

with this method such as every dual-stack device still requires an IPv4 address; two routing tables
must be maintained in every dual-stacked router; as two stacks must be run at the same time,
additional memory and CPU power will be required; moreover, every network requires its own
routing protocol; supplementary security concepts and rules must be set within firewalls to be
suited to each stack; a DNS with the ability to resolve both IPv4 and IPv6 addresses is required;
finally, all programs must be able to choose the communication over either IPv4 or IPv6, and
separate network management commands are required [32].

2.4.2

Translation

There are various translations mechanisms also applied to enable the communication between
IPv4-only applications and IPv6-only applications. Translation simply means the direct conversion
of protocols from IPv4 to IPv6 or vice versa, which might result in transforming those two protocol
headers and payload. This mechanism can be established at the network, transport, and application
layers of the protocol stack. The translation mechanisms can be either stateless or stateful. Stateless
means that the translator can perform every conversions separately with no reference to previous
packets, while stateful is the vice versa, i.e., it maintains some form of state in regard to previous
packets. The translation process can be performed in either end systems or network devices [33].

2.4.2.1 Stateless IP/ICMP Translation

The fundamental part of the translation mechanism in the translation process is the conversion of
IP and ICMP packets. All translation methods, which are used to establish communication between
IPv6-only and IPv4-only hosts, for instance the Network Address Translation-Protocol Translation
(NAT-PT) or BIS, apply an algorithm known as Stateless IP/ICMP Translator (SIIT). The function
of this algorithm is to translate packet-by-packet the headers in the IP packet between IPv4 and
IPv6, and also addresses in the headers among IPv4, IPv4-translated or IPv4-mapped IPv6
33

addresses. However, this does not mean IPv6 hosts can get an IPv4 address or route packets, but
this assumes that each IPv6 host can have a temporary assigned IPv4 address [34].

Figure 2.5: Stateless IP/ICMP Translator Model (Vienna University of Tech., 2012)
The above figure indicates an algorithm that designates a two-way translation between IPv4 and
IPv6 packet headers or between ICMPv4 and ICMPv6 messages. The interpretation has been
arranged so that UDP and TCP header checksums are not influenced during the process. More
importantly, SIIT is currently used as the backbone for NAT-PT and BIS (RFC2765 2000)

2.4.2.2 Network Address Translation-Protocol Translation (NAT-TP)

From the figure above, the router is used as a translation communicator between an IPv4-only
network and an IPv6-only network. NAT-PT is considered as a stateful translator functioning in
the network layer with the SIIT algorithm. The main role of a NAT-PT device, such as routers or
servers, is to support numerous IPv6 nodes by assigning a temporary IPv4 address for each, which
permits native IPv6 hosts and applications to communicate with native IPv4 hosts and applications.
In general, it acts as a communication proxy with IPv4 peers. Proxy means a server that stands
between an external network (such as Internet) and an organization's internal (private) networks
and serves as a firewall. It prevents external users from directly accessing the internal information
34

resources, or even knowing their location. All external requests for information are intercepted by
the proxy server and checked for their validity, and only authorized requests are passed on to the
internal server [35]. However, this mechanism still possesses limitations similar to IPv4 NAT
such as point of failure, decreased performance of an application level gateway (ALG), reduction
in the overall value and utility of the network. NAT-PT also prevents the ability to implement
security at the IP layer (RFC2766 2000).

Figure 2.6: Deployment of IPv6 using NAT-PT

RFC 3142 defines the Transport Relay Translation (TRT) method. This is the most common form
of NAT-PT but relies on DNS translation between AAAA and A records known as DNS-ALG as
defined in RFC 2694.

2.4.2.3 Bump in the Stack

The BIS method means there are three more fields inserted into the structure of layers as indicated
in Figure 20. There will be three additional components, name resolver extension, address mapper,
and translator, and are layers between the application and network layers. The BIS method is
35

specially designed for communication between IPv4 applications on an IPv4-only host and IPv6only hosts. The term bump is used to describe extra modules in a TCP/IP stack. Firstly, the
extension name resolver uses DNS lookups to see if the node supports only IPv6. Secondly, the
address mapper will allocate a temporary IPv4 address for the IPv6 node and save that in the
address mapping caches [36]. Thirdly, the translator translates packets between IPv4 and IPv6. In
the circumstances that a program needs to transmit data from and to a host, which supports only
IPv6, those layers will play their roles to map an IPv6 address into the IPv4 address of the IPv4
host. Nevertheless, those temporary IPv4 addresses are only apparent in the end system and
normally come from a private address space. Therefore, BIS is only suitable to programs that
include no address-dependent fields in application layer protocols. One more thing is that this
method can only be implemented on end systems. The reason for this limitation is that it is easier
for translation processes to solve application to network interoperability problems but it would be
harder to control on a larger scale (RFC2767 2000).

Figure 2.7: Bump in the Stack model (TechWeb 2009)

36

Those are three representatives for the translation mechanism, which are currently used in the IPv6
transition. With this method, we can easily connect devices in networks. Furthermore, it requires
neither modifications to nodes nor additional applications to be established on networks. In
addition, we only need to make some adjustments on the boundary routers. However, nothing is
perfect and this translation is also not an exception. Although it has some benefits, the
disadvantages it possesses are also taken into consideration. At first, the first drawback of the NAT
techniques is that the end-to-end security is not supported. Secondly, due to the function of NAT,
routers would become the single point of failure, which means if anything occurs to routers, the
whole networks could collapse. Finally, the level of complexity in IP addresses would be
increased, which can cause the loss of information in the process [37].

2.4.3

Tunnelling

Figure 2.8: Tunnelling transition method (H3C 2003)

37

The last category for IPv6 transition process is tunnelling as presented in Figure 2.8 above. This
is used to transfer data between compatible networking nodes over incompatible networks. There
are two ordinary scenarios to apply tunnelling: the allowance of end systems to apply offlink
transition devices in a distributed network and the act of enabling edge devices in networks to
inter-connect over incompatible networks. Technically speaking, the tunnelling technique utilizes
a protocol whose function is to encapsulate the payload between two nodes or end systems. This
encapsulation is carried out at the tunnel entrance and the payload is de-capsulated at the tunnel
exit. This process is called tunnelling. Therefore, the main issue in deploying tunnelling
mechanism is configuring the tunnel endpoints and determining positions for applying
encapsulation. Based on my research, this mechanism is generally attained via manual or toolbased parameter entry, existing services like DNS or DHCP, or by taking into use the embedment
of information into IP addresses or applying an IPv6 anycast address (Bi, Wu and Leng 2007).
Network devices can achieve the two processes of encapsulation and de-capsulation at tunnel
endpoints. In general, tunnelling mechanism is a simple deployment with point-to-point
configuration. Nevertheless, tunnels can also be implemented hierarchically and sequentially.
Hierarchical structure is applied in the circumstances that there are transition tunnels operating
alongside with security or QoS tunnels. Sequential structure can be established in an end-to-end
path, from end systems to local gateways, and beyond. As a result, these two establishments always
increase requirements for processing and packet delay. There exist different tunnelling methods
which include: 6to4, ISATAP, Teredo, DSTM, and 6over4. Tunnels may be manually configured
or automatically configured. (Qing-weil and Lin 2007).

38

2.4.3.1 IPv6 Over IPv4 (6over4) Tunnel

Figure 2.9: 6 over 4 Model (Microsoft 2011)

Figure 2.9 above illustrates the 6over4 method that inserts IPv4 addresses into IPv6 address link
layer identifier part and defines Neighbour Discovery (ND) over IPv4 by using organization-local
multicast. In this method, the multicast enables IPv4 network to perform as a virtual LAN and the
IPv6 target address will be resolved on this network to get the destination IPv4 address for the
tunnel endpoint. This mechanism accommodates all features of IPv6 such as end-to-end security,
multicast and stateless auto-configuration. It also bears resemblances to the Intra-Site Automatic
Tunnel Addressing Protocol (ISATAP) method. (Bouras, Karaliotas and Ganos 2003).

2.4.3.2 Dual Stack Translation Mechanism (DSTM)

Figure 2.10: DSTM Model (Wedel 2008)

39

The DSTM mechanism, which is expressed in the Figure above, allows temporary IPv4 addresses
to be allocated for end systems with dual stack enabled, and connection to networks that support
IPv6 only. The general idea is that IPv4 packets will be tunnelled to pass through IPv6 network to
get to the global IPv4 Internet. In the event that a DSTM end system starts sessions, a DHCPv6
server has been modified to acquire a temporary IPv4 address and the address of DSTM border
router, to which packets are later tunnelled. On the other hand, in case a node supporting only IPv4
initiates sessions, the request sent to DNS for the lookup process would be directed to an adjusted
DNS server in the DSTM domain, at which a temporary IPv4 address will be appointed for the
end system. As a result, incoming packets are tunnelled to this IPv4 address (Bouras, Karaliotas
and Ganos 2003).

2.4.3.3 6to4 Automatic Tunnelling

Automatic means that tunnel configuration is carried out with no additional management. As
shown in the Figure below, this method is considered as the most popular choice in the field of
automatic tunnelling technique. When in operation, this mechanism will have IPv6 traffic
tunnelled upon IPv4 networks within isolated 6to4 networks. A special prefix containing the IPv4
address of its 6to4 gateway is supposed to be present in each 6to4 network, which enables tunnel
endpoint addresses are acquired easily and requires no IPv6 administrative work.
Then connection from 6to4 network to the rest of the IPv6 network is established via a dual stack
local gateway and a dual stack relay router. Therefore, every IPv6 packet is directed to the gateway.
These kinds of tunnels would transfer the traffic to appropriate gateway with suitable IPv4 address.
(RFC6343 2011).

40

Figure 2.11: 6to4 Automatic Tunnelling Model

41

2.4.3.4 Teredo

Figure 2.12: Teredo method (Microsoft 2011)

Teredo mechanism is a technique for assigning addresses and providing tunnelling services
automatically to allow IPv6 connectivity across IPv4 Internet. This method is supposed to be the
solution for the lack of 6to4 functionality by supporting the tunnel for IPv6 packets between hosts
within sites while 6to4 method only allows providing tunnels for IPv6 packets between edge
devices. Based on my research, networks which are applying IPv6, face another problem of NATs.
Because of its nature, IPv4-encapsulated IPv6 packets have the header set to 41, which prevents
them to pass through typical NATs. Accordingly, because UDP messages can be translated
universally by NATs and can traverse multiple layers of NATs, Teredo encapsulates the IPv6
packet as an IPv4 UDP message, provided that NAT supports UDP port translation, it supports
Teredo. (Huang, Quincy and Lin 2005).
42

2.4.3.5 Tunnel Broker

Figure 2.13: Tunnel Broker model (Netnam Ltd. 2011)

This is another approach to IPv6 with the support of dedicated servers, known as Tunnel Brokers
as illustrated in the Figure above, to answer automatically tunnel requests from users, which is
believed to increase IPv6 growth with connected hosts and to support access to IPv6 networks.
Besides, this method makes it easy for IPv6 ISPs to manage access control by applying own
policies on network usage. This is where users make connection for registering and activating
tunnels. Then, dedicated servers or Tunnel Brokers control the management of tunnels with
activities such as creation, modification and deletion for users. In addition, to support networks on
a larger scale, this method can distribute the workload to some tunnel servers by delivering orders
to concerned tunnel server when there is a need to manage a tunnel. Finally, connections between
tunnel brokers and servers can occur with IPv4 or IPv6. (Chen, et al. 2002).
Generally, the tunnelling mechanism allows us to connect isolated IPv6 nodes and networks
whether or not the ISP has been upgraded to IPv6. Moreover, it also takes advantage of emerging
IPv6 services while remaining connected to the IPv4 world. However, its encapsulation and decapsulation take more time and CPU power, and add more complications to troubleshooting and

43

network management as well. One more thing is that those tunnel endpoints can be single points
of failure and they can be vulnerable to security attacks. (Waddington and Chang 2002).

2.5

Summary of the Three Transition Mechanisms

Below is the summary table containing the advantages and disadvantages for three main transition
mechanisms as discussed above.

Table 2.3: Summary of the three transition methods

44

CHAPTER THREE
METHODOLOGY
This chapter will cover the methodology employed in this study, the data collection method and
the analysis method used will be discussed. This chapter also describes simulation models used
with OPNET Modeler simulation software. Both data analysis and data collection will be
performed with OPNET Modeler
In order to achieve the objectives of this thesis, theoretical and experimental steps have been
adopted as the methodology of the thesis work. Most of the theoretical developments with
literature review have been furnished in chapter 2. The experimental setup model will be discussed
later in this chapter. The simulation software (OPNET) which is used for the experiment will also
be introduced later in the chapter.

3.1

The Network Model

This section describes the network model that is used for the experiment, and measurements that
will be gathered from these networks during the simulation. Two different networks have been
modelled; one is a simple network consisting of one client, a router and an FTP or Video Server.
The second one is modelled as a campus network. This network is consists of LANs, routers, an
IP cloud, switches and servers.

3.1.1

The Simple Network Model

The design of the simple network is shown in Fig. 3.1 below. The experimental setup consists of
a client, a router, and an FTP or Video Server. Interconnection between the client, the router, and
the server is done using 10baseT duplex links. A 10BaseT duplex link represents an Ethernet

45

connection operating at 10 Mbps. The same network design will be used for both IPv4 and IPv6
simulations and also for the IPv6 transition mechanisms that will be simulated and studied. The
TCP receive buffer sizes for both the client and server are set to 8760 bytes. Windows uses 8760
bytes by default for Ethernet. The number 8760 is 6 x 1460 and is the amount of data a full Ethernet
frame can carry which is the MSS (Maximum Segment Size) for Ethernet by default. The router
is configured to forward packets at the rate of 40,000 packets per second. The router model
implements a store and forward type of switching methodology. The packet switching rate is at
500,000 packets per second and its set to support central processing and has a memory size of 32
MB. Detailed description of the configuration of the network is presented in Appendix A.

Fig. 3.1: Simple Network Layout

3.1.2

The Campus Network Model

The campus network model comprises of two campuses connected together via an IP cloud. Each
campus contains three departments. Campus A is made up of the following departments: Electrical
Engineering (EE), Computer Science (CS) and Information Management Technology (IMT). Each
department has three Ethernet workstations connected to a switch, thus forming three small Local
Area Networks (LANs). The EE department has two Ethernet servers (Database and HTTP server)
connected to its switch and the IMT department has a File server (FTP Server) and an Email server
connected to its switch. Each of the three switches in Campus A is connected to a router which is
connected to an IP cloud or Internet Backbone.

46

Campus B is made up of the following departments: Telecommunications Engineering (TE),

Computer Engineering (CE), and Project Management (PM). Each of these departments consists
of three workstations or computers connected to a switch thus forming three small LANs just like
in Campus A. The three switches are then connected to a router and then to the IP cloud. There are
no Ethernet servers on Campus B but Campus B can access all the servers in Campus A through
the IP cloud and the router in Campus A.
The computers in Campus A and B are configured to support different packet sizes and
applications depending on if the network is implemented for IPv4, IPv6 or one of the transition
mechanisms (6to4 tunnelling or manual tunnelling). The workstations on campus A and B are also
configured to handle FTP, HTTP, Database and Email client services. The buffer size for each
computer on both campus networks is set to 8760 bytes. The servers on Campus A are configured
to provide FTP, HTTP, Video and Database services respectively according to the server name.
All the links used for interconnection between workstations and switches, servers and switches,
switches and routers, are 100BaseT duplex links. PPP DS3 links are used for connections between
routers and the IP cloud (Internet). The rate at which packets are switched from the switch
processor to the appropriate output port is set to 500,000 packets per second. Switches are set to
support IEEEs 802.1w rapid spanning tree protocol. The switch implements the Spanning Tree
algorithm in order to ensure a loop free network topology. The routers are configured to forward
packets at the rate of 40,000 packets per second and are set to support central processing. The
setups and detailed configurations of the IPv4, IPv6, 6to4 tunnelling and manual tunnelling
implemented network scenarios will be discussed in Appendix A.

47

Fig. 3.2: Campus A Network Layout

48

Fig. 3.3: Campus B Network Layout

Figure 3.2 and 3.3 above show the Campus network models used for this research work. The
implementation will include a behavioural study of experimental IPv4, IPv6, 6to4 tunnelling and
manual tunnelling networks with varied payloads. Detailed configuration of how to set up and vary
the FTP traffic and video traffic is explained in Appendix A and B.

49

3.2

Performance Metrics Used in Computer Networks

Performance metrics are the criteria used to evaluate the performance of a system [7]. There are a
number of metrics applicable to computer networks, but the focus of this thesis will be on those
metrics which are of greatest relevance to network performance [9]. New innovations are being
employed to accurately monitor, measure and study their effects on network performance. The
mostly concerned performance metrics include the following [6] [9]:
i.

Throughput

ii.

Packet Loss

iii.

Latency

iv.

Delay

v.

Jitter and

vi.

Bandwidth

Throughput
This refers to the average rate of successful data or message delivery over a communication link
or system and is usually measured in bits per second (bits/s or bps) [6].

Packet Loss
Packet loss and error metrics are indicative of the network congestion conditions and/or
transmission errors and/or equipment malfunctioning. They basically measure the fraction of
packets lost in a network due to buffer overflows or other reasons or the fraction of error bits or
packets [9].

Latency

50

Latency refers to the amount of time it takes for data to travel from one location to another across
a network. It is usually measured in millisecond (ms). It is sometimes referred to as delay because
software may often wait to execute some function while data travels back and forth across the
network [11] [6].

Delay
In a general sense, delay refers to a lapse of time. Delay metrics also assess the network congestion
conditions or effect of routing changes. The delay of a network specifies how long it takes for a
bit of data to travel across the network from one node or endpoint to another. In Internet Protocol
(IP) network, this is generally the round trip delay for an IP packet within the IP network
[6][9][15].

Jitter
Jitter is often used as a measure of variability over time of the packet latency across a network. A
network with constant latency has no variation (or jitter). Packet jitter is expressed as an average
of the deviation from the network mean latency. It is usually referred to as Packet Delay Variation
(PDV) [13]. Jitter often refers to variation in the amount of latency [11].

Bandwidth
Bandwidth means the used capacity or available capacity. It may also refer to consumed
bandwidth, corresponding to achieved throughput which is the average rate of successful data
transfer through a communication path [14]. Bandwidth metrics, in practice, assess the amount of
data that a user can transfer through the network in a time unit and may be dependent or
independent from the existing network traffic [9].

51

3.3

OPNET Modeler

OPNET stands for Optimized Network Engineering Tool. It is a comprehensive engineering

system capable of simulating large communications networks with detailed protocol modelling
and performance analysis [11]. It provides a comprehensive framework for modelling wired as
well as wireless network scenarios. The presence of features like a graphical user friendly interface,
object based modelling, integrated data analysis tool, and dynamic event scheduled simulation
kernel have made OPNET a sophisticated tool for workstation based modelling and simulation.
Simulation models are organized in a hierarchy consisting of three main levels: the simulation
network models, node models and process models. The top level refers to the simulation scenario
or simulation network. It defines the network layout, the nodes and the configuration of attributes
of the nodes comprising the scenario. The network editor is a tool in OPNET mainly used to build
network models. A network can be constructed in such a way that it contains sub networks
connected with nodes through links. The idea of incorporating sub networks helps in distinguishing
and managing the network model.
The node models are at the second level in the hierarchy and consist of an organized set of modules
describing the various functions of the node. The modules in the nodes are implemented using
process models, the lowest level in the hierarchy. The node editor is a tool in OPNET used for
creating models of nodes. Behaviour of each network object is defined by this node editor. Node
instances are created in the network using node models. Packet streams and statistic wires are
connected with different modules to define a node. These connections between the modules enable
the flow of packets and status information. OPNET node models have an internal modular
structure.

52

Modules

Packet Streams

Statistic Wire

Fig. 3.4: Node Editor

Process models consist of finite state machines, definitions of model functions, and a process
interface that defines the parameters for interfacing with other process models and configuring
attributes. Finite state machine models are implemented using Proto C, which is a discrete event
library based on C functions. The finite state machines consist of states and transitions in the form
of Icons and lines respectively. Transitions describe the possible movement of a process from state
to state and the conditions allowing such a change. The process editor is a tool that allows for the

53

creation of process models. The hierarchal structure of the models, coupled with support for C
language programming, allows for easy development of communication or networking models.

States

Transitions

Fig. 3.5: Process Editor

3.3.1

OPNET Editors

The three main editing tools in OPNET Modeler have been discussed above. There are many other
editors that facilitate and simplify the modelling and simulation tasks by means of easy-to-use
graphic user interfaces. Other editors that are used in this thesis include the following:

54

Project Editor: Project Editor is the interface used for the simulation task. Simulation projects
and scenarios were managed by the Project Editor. The Project Editor can be accessed by
creating a new project, or by opening an existing project. The Project Editor made it possible to:

Create and edit network models

Create and manage project scenarios

Configure and import network topology

Configure and import network traffic

Customize the network environments

Verify link connectivity

Record packet flow animation and node movement animation for subnet

Configure and run simulations for project scenarios.

These tasks were achieved by choosing corresponding menu items or clicking the shortcut tool
buttons in the Project Editor. These Menu items as shown in Fig. 3.6 below include: File, Edit,
View, Scenario, Topology, Traffic, Services, Protocols, Flow Analysis, Discrete Event Simulation
(DES), Design, Windows and Help. OPNET network models were created within Project Editor.

55

Fig. 3.6: Project Editor

Link Editor: allowed for the creation and definition of a link model. A link model represents a
physical connection between nodes. In the Link Editor, data rate, bit error rate, channel count,
propagation delay, transmission delay, error model, error correction model, supported packet
formats, were defined. Link model supports the following link types: simplex, duplex, bus, or bus
tap.

56

Fig. 3.7: Link Editor

Packet Format Editor: is a tool that allowed for the defining of the internal structure of the packet
fields. OPNET Modeler allows one to model packets in both unformatted and formatted forms.
For formatted packets, each field in the packet is named. Fields of a formatted packet can be
accessed by name. For unformatted packets, each field in the packet is indexed. Fields of an
unformatted packet can be accessed by index. Here the size of the box of a specific field varies
with respect to the number of bits defined for it.

57

Fig. 3.8: Packet Format Editor

Probability Density Function Editor: PDF Editor made it possible to explain the spread of
probability over a wide range of outcomes. It was used to create, edit, and view probability density
functions of a data sequence. Simulation statistical results were exported to the PDF Editor for
analysis as well. Note that one can modify an existing PDF model based on a data sequence, or
make a new PDF model. The modified or newly created PDF model can be loaded in code by
using OPNET Distribution APIs in the process model to model stochastic processes such as system
failure, packet size, inter-arrival times, etc.
ICI Editor: Interface Control Information is an OPNET internal structure that is able to carry
information and facilitate interrupt-based inter-process communications. A process can access the

58

ICI objects associated with interrupts to communicate with other processes. ICI Editor can be used
to visually edit the ICI format.
OPNET internal structures are defined for Proto-C. These structures are not general-purpose data
structures. They are particularly used in OPNET simulation to facilitate design and development.

Fig. 3.9: ICI Editor

Probe Editor: In OPNET simulation carried on in this work, there were many types of statistics
collected global statistic, node statistic, link statistic, path statistic, etc. After the network was
constructed and simulated, it became necessary to collect the resultant data to analyse the working
of the network. The Probe Editor was one of the tools used to specify what data has to be collected
from the simulation output.

59

Fig. 3.10: Probe Editor

Simulation Sequence Editor was used to add constraints to the simulations. It provided the
options to specify the duration and other attributes on the particular simulation set to get the
required results.

60

Fig. 3.11: Simulation Sequence Editor

Simulation Results Browser: In this thesis work, for the simulation model implemented, there
were several scenarios to simulate. These scenarios were based on different topologies, routings,
traffic, load parameters, etc. Further, in every scenario, there were many statistics to probe. In
OPNET Modeler, simulation Results Browser allowed one to view and compare all simulation
results for all scenarios of the simulation project in a unified user interface as shown in Fig. 3.11
below. The analysis of the results obtained from this interface will be presented in Chapter 4 of
this thesis.

61

Fig. 3.12: Simulation Results Browser

3.3.2

OPNET Programming

The programming language for writing OPNET Models is called Proto-C. There are not many
syntax differences between programming in C and Proto-C, since Proto-C preserves generality by
incorporating all the capabilities of the C/C++ programming language, i.e., one can program
OPNET models in the same way as one programs C/C++ applications. The major difference is the
methodology adopted by Proto-C to program models. Unlike programming standalone C/C++
applications, Proto-C is designed to handle OPNET predefined data types via an existing
simulation engine, which can be regarded as a half-done application in a standalone C/C++
application. This simulation engine needs to incorporate the Proto-C model code to generate a final
62

runnable and debuggable standalone simulation application. The simulation engine can be
regarded as pre-written skeleton or framework which is the kernel in every simulation application.
The OPNET model code is the custom part of the simulation application. The OPNET
model code is inserted into the designated positions of the simulation engine framework
to generate the final complete source files. These files will be compiled and linked into
a normal C/C++ application. The simulation actually starts only when this application
is loaded into the operating system.
However, unlike programming general C/C++ applications, to write OPNET model
code one will not directly participate in the whole application-building process, i.e.,
one does not touch the whole C/C++ sources. What will be written is the custom parts of the
sources which are abstracted as process models in OPNET Modeler. Further, in the
process model, Proto-C adopts a methodology called state transition diagrams (STDs)
to help one construct the model logic and handle the underlying C/C++ code. In short,
in OPNET programming one does not program the whole sources of an application: just
the custom parts of the simulation application. The entire C/C++ simulation application
building process will be handled by OPNET Modeler.
OPNET modelling code can be written in three places:

The process model via Process Editor or Transceiver Pipeline states the OPNET
Modelers kernel GUI services

Text file via external model access (EMA) interfaces

Third-party programs via external tool support (ETS) interfaces.

63

3.4

The Project/Scenario Workflow in OPNET Modeler

After getting to know the simulation tool, the work flow of the tool needs to be understood. Also
understanding ones goals for the simulation is important because it helps in choosing what aspects
is to be modelled. The workflow of the simulation done in this thesis is divided mainly into four
steps; creating new network models, choosing individual statistics, running simulations and
viewing/analysing the results.
Figure 3.13 below shows the project workflow used in OPNET simulation and each stage is
discussed as follows:

Creating the Network Model: All the necessary network components are selected from
the object palette and a network is created on the workspace.

Setting the parameters for the network components and choosing the applications: In
this step, the parameters of the network components are set such as IP address of the hosts,
packet and buffer sizes etc. Different types of applications required for the network are
created.

Choose individual statistics: Once the network is ready, the statistics required for our
simulation are chosen. As discussed earlier, the statistics collected are usually global
statistics, node statistics, link statistics, and/or path statistics.

Set simulation parameters: Parameters such as duration for which the simulation is run
and values per statistic are set.

Run simulations: Simulation is run for the specified time set in the previous step.

Errors: All the errors encountered during simulation are displayed in the simulation
window. Errors are usually caused due to parameter settings in which case the simulation

64

process is repeated from step 2. Absence of errors takes us to the next step of the simulation
process.

Viewing and analysing the results: In this step, the results are analysed to determine the
efficiency and deficiency of the network. The analysis of the simulation results will be
carried out in the next chapter.

Rerun with different set of parameters: If not satisfied with the results or are not able to
analyse network activity under different parameter settings, the entire procedure from step
2 is repeated.

End of simulation: The simulation is said to be completed when the user is satisfied with
the results.

65

Yes

Create Network
Model

Set the
parameters
for network
components
and choose
the
applications

Choose
Individual
Statistics

Set the
Simulation
Parameters

No
Run Simulation

Errors

Yes

View and Analyse

the Results

Rerun with
different set
of parameters

No
End of
Simulation

Fig. 3.13: Project Workflow in OPNET

66

CHAPTER FOUR
SIMULATION RESULTS AND ANALYSIS
In this chapter, the properties of IPv4, IPv6, 6to4 tunnelling and Dual Stack are examined first in
a Campus network and then in a Simple network which has minimal configurations. The different
types of traffic used for simulation and analysis in this thesis include: FTP, HTTP, Database and
Video traffic. In this chapter analysis will be done only on FTP and Video data traffic. In the first
section, the analysis will be performed with and without HTTP and Database background traffic.
In the next section, the analysis will be performed with and without FTP and Database background
traffic.

4.1

Campus Network Simulation of Networks with FTP Traffic Only

The campus networks are loaded with only FTP traffic starting at 1 KB up to 1 GB with an interrequest time of 2000 seconds and a Best Effort type of service. Table 4.1 gives the summary of the
values used for the four graphs in each subsection. The performance metrics of the four IP
networks are then measured and analysed. All simulations were done for a period of 30 minutes.

Table 4.1: Parameters used for Campus Network Analysis

Command Mix

Inter-Request

Files Size

Type of

(Get/Total) (%)

Time (Sec)

(Bytes)

Service

Graph (a)

100

2000

1 KB

Best Effort

Graph (b)

100

2000

1 MB

Best Effort

Graph (c)

100

2000

100 MB

Best Effort

Graph (d)

100

2000

1 GB

Best Effort

67

4.1.1

Ethernet Delay Analysis of FTP Packets with no background traffic

This section shows the graphs of Ethernet Delay with only FTP traffic loaded. The graphs shows
the end-to-end delay of all packets received by all the stations in the network. It can be observed
from Figure 4.1, that an increase in the FTP traffic leads to an increase in the number of packets
thereby leading to an increase in the network delay.

(a)

(b)

(c)

(d)

Fig. 4.1: Ethernet Delay with only FTP traffic

The Ethernet Delay of the IPv4 network is the highest as can be seen from the graphs of Figure
4.1. This is because of the fast processing ability of IPv6 protocol header as the flow label helps
68

in the fast routing of packets. The Ethernet delay of IPv6, 6to4 tunnelling and dual stack networks
can be seen to be almost the same in all the graphs.

4.1.2

Download Response Time Analysis of FTP Packets with no

background traffic

Figure 4.2 shows the statistics of the IPv4, IPv6, 6to4 Tunnelling and Dual Stack network response
times. The response time is measured from the time a client application sends a request to the
server, to the time it receives a response packet.

(a)

(b)

(c)
Fig. 4.2: Download Response Time with only FTP traffic
69

The response time of IPv6 when the FTP traffic is 1 KB is the lowest as can be seen in Figure
4.2(a). The response times for the 1 MB and 100 MB graphs of Figures 4.2(b) and (c) respectively
are almost the same for all the networks. An increase in FTP traffic can be seen to lead to an
increase in the response times for all networks.

4.1.3

Throughput Analysis of FTP Packets with no background traffic

Figure 4.3 shows the comparison between the throughputs of IPv4, IPv6, 6to4 Tunnel, and Dual
Stack networks. The graphs show the average number of packets successfully received or
transmitted by the receiver or transmitter channel per second. This is why the throughput in bits/sec
increases from Figure 4.3(a) to (d). It can also be observed that the IPv4 network has the lowest
throughput in all plots. The difference in throughputs between IPv6, 6to4 and Dual Stack is
negligible in all the cases.

(b)

(a)

70

(d)

(c)
Fig. 4.3: Throughput with only FTP traffic

4.1.4

Packet Latency Analysis of FTP Packets with no background traffic

Figure 4.4 shows the graphs of Packet Latency collected for all the networks with only FTP traffic.
Packet latency is measured in seconds and represents the delay experienced by an IP datagram
from the time when the datagram arrives at the IP layer to the time it is dispatched. The packet
latency reduces as the amount of FTP traffic increases and also varies among the different networks
depending on the FTP packet size loaded into the network.

(b)

(a)

71

(c)
Fig. 4.4: Packet Latency with only FTP traffic

4.1.5

(d)

Utilization Analysis of FTP Packets with no background traffic

Figure 4.5 shows the comparison between the utilization of IPv4, IPv6, 6to4 Tunnel, and Dual
Stack networks. It has no unit and represents the percentage of the consumption to date of an
available channel bandwidth, where a value of 100.0 indicates full usage. In this thesis, the
utilization measured is the movement of traffic on the point-to-point link from Campus A network
to the Internet cloud. It can be seen that the utilization for all the IP networks are almost the same.
Also utilization increases as data traffic increases from Figure 4.5(a) to (d).

(a)

(b)
72

(c)

(d)

Fig. 4.5: Utilization with only FTP traffic

4.2

Campus Network Simulation of Networks with FTP, HTTP and

Database traffic

In this section, the campus networks are loaded with FTP, HTTP and Database traffic. Only FTP
traffic is varied using the same format as Table 4.1 in section 4.1. HTTP and Database traffic are
set at constant values for all cases. The performance metrics of IPv4, IPv6, 6to4 Tunnelling and
Dual Stack networks are then measured and analysed. The HTTP traffic is configured with a page
inter-arrival time of 2000 seconds, 100 objects per page and the type of service set to background.
The Database traffic is configured with a transaction inter-arrival time of 2000 seconds, a
transaction size of 1 MB, and the type of service is also set to background. All simulations are
done for a period of 30 minutes.

4.2.1

Ethernet Delay Analysis of FTP Packets with background traffic

This section shows the graphs of Ethernet Delay with HTTP and Database traffic constant while
FTP traffic is varied like in Table 4.1. The graphs shows the end-to-end delay of all packets
received by all the stations in the network. The graphs are the same as those in Figure 4.1.
73

4.2.2

Download Response Time Analysis of FTP Packets with background

traffic

Figure 4.6 shows the statistics of the IPv4, IPv6, 6to4 Tunnelling and Dual Stack network
download response times with HTTP and Database traffic constant while FTP traffic is varied. The
Dual Stack and IPv6 networks have the highest response times when FTP traffic is 1 KB. With 1
MB and 100 MB of FTP data, the Dual Stack network has the highest response time. Of the four
networks, the 6to4 Tunnel network has the best download response time. An increase in FTP traffic
can be seen to lead to an increase in the response times for all networks.

(b)

(a)

(c)
Fig. 4.6: Download response time with FTP traffic and background traffic
74

4.2.3

TCP Delay Analysis of FTP packets with background traffic

Figure 4.7 shows the graphical representation of the IPv4, IPv6, 6to4 Tunnelling and Dual Stack
network TCP delays with HTTP and Database traffic constant while FTP traffic is varied. It is
measured from the time an application data packet is sent from the source TCP layer to the time it
is completely received by the TCP layer in the destination node. In Figure 4.7(a), (b) and (c), the
TCP delays of the Dual Stack network is highest. The TCP delay for the IPv4 and 6to4 tunnel
networks are the same on all the graphs and are relatively low when compared to the other two
networks. With an FTP data of 1 GB, TCP delay is at the same level for all networks.

(a)

(b)

(c)
Fig. 4.7: TCP Delay with FTP traffic and background traffic
75

(d)

4.2.4

Throughput Analysis of FTP Packets with background traffic

Figure 4.8 shows the graphical view of the IPv4, IPv6, 6to4 Tunnelling and Dual Stack network
throughputs with HTTP and Database traffic constant while FTP traffic is varied. In this thesis,
the throughput measured is the forward movement of traffic on the point-to-point link from the
Internet cloud to Campus A. Just like the previous section, the throughput increases with an
increase in FTP file sizes from 1 KB to 1 GB. However, in this case the throughput (in bits/sec)
for each graph is much higher than that of its counterpart in the previous section due to the fact
that there is more traffic in the network. The throughputs of the Dual Stack and the 6to4 tunnel
networks have very little differences in all the graphs.

(a)

(c)
Fig. 4.8: Throughput with FTP traffic and 76
background traffic

(b)

(d)

4.2.5

Packet Latency Analysis of FTP Packets with background traffic

Figure 4.9 shows the graphs of Packet Latency collected for all the networks with FTP traffic
varied while HTTP and Database traffic are constant. The packet latency reduces as the amount of
FTP traffic increases and also varies among the different networks depending on the FTP packet
size loaded into the network. It can be observed from the graphs that IPv6 has the highest packet
latency while Dual Stack and 6to4 Tunnel networks have the least packet latency on the average.

(a)

(b)

(d)

(c)
Fig. 4.9: Packet Latency with FTP traffic and background traffic

77

4.2.6

Utilization Analysis of FTP packets with background traffic

Figure 4.10 shows the comparison between the utilization of IPv4, IPv6, 6to4 Tunnel and Dual
Stack networks with FTP traffic varied while HTTP and Database traffic are constant. The
utilization measured is the movement of traffic on the point-to-point link from Campus A network
to the Internet cloud. It can be seen that the utilization for all the IP networks are almost the same.
Also utilization increases as data traffic increases from Figure 4.10(a) to (d).

(a)

(b)

(c)

(d)

(c)

Fig. 4.10: Packet Latency with FTP traffic and background traffic

78

4.3

Simple Network Simulation of Networks with Video Traffic Only

The simple networks are loaded with only video conferencing traffic. The traffic is configured
with four different sets of parameters which are shown in the table below.
Table 4.2: Parameters used for Simple Network Analysis

Graph (a) (Case 1)

Graph (b) (Case 2)

Graph (c) (Case 3)

Graph (d) (Case 4)

Frame Inter-arrival

Frame Size

Time Information

Information (bytes)

10 frames/sec

128120 pixels

Interactive

(17280 bytes)

Multimedia

128240 pixels

Interactive

(34560 bytes)

Multimedia

128120 pixels

Interactive

(17280 bytes)

Multimedia

128240 pixels

Interactive

(34560 bytes)

Multimedia

10 frames/sec

15 frames/sec

15 frames/sec

Type of Service

The performance metrics of the four IP networks are then measured and analysed. All simulations
were done for a period of 30 minutes.

4.3.1

Ethernet Delay Analysis of Video Traffic with no background traffic

This section shows the graphs of Ethernet Delay with only Video traffic loaded. The graphs show
the end-to-end delay of all packets received by all the stations in the network. It can be observed
that the graphs of Figure 4.11(a) and (c) look very much alike while that of Figure 4.11(b) and (d)
have little or no difference. There is also no difference in the Ethernet delay of the four networks.
This is as a result of the absence of background traffic.

79

(b)

(a)

(c)

(d)

Fig. 4.11: Ethernet Delay with Video traffic only

4.3.2

Packet Delay Variation Analysis of Video Traffic with no background

traffic

Figure 4.12 shows the comparison between the packet delay variation of IPv4, IPv6, 6to4 Tunnel,
and Dual Stack networks. The Packet Delay Variation (PDV) is the variance among end to end
delays for video packets. End to end delay for a video packet is measured from the time it is created
to the time it is received. The PDV for IPv6 is higher than that of other networks for the first graph
80

and third graphs (i.e., Figure 4.12(a) and (b) respectively). The PDVs of IPv6 and Dual Stack are
higher than those of IPv4 and 6to4 Tunnelling in Figures 4.12(b) and (d). Steady state nature of
the graphs are as a result of the absence of background traffic.

(b)

(a)

(c)

(d)

Fig. 4.12: Packet Delay Variation with Video traffic only

4.3.3

Packet Endto-End Delay Analysis of Video Traffic only

Figure 4.13 shows the statistical graph of packet end to end delay for the four networks being
measured in the absence of background traffic. Packet End to End delay is measured in seconds
and is the time taken to send a video application packet to a destination node application layer. It
81

can be seen from the graphs that there is minimal difference in packet end-to-end delay. The packet
end-to-end delay is more in the cases of Figure 4.13(b) and (d). This is as a result of an increase in
the frame sizes of the video traffic.

(b)

(a)

(c)

(d)

Fig. 4.13: Packet End-to-End Delay with Video traffic only

4.3.4

Throughput Analysis of Video Traffic with no background traffic

Figure 4.14 shows the comparison between the throughputs of IPv4, IPv6, 6to4 Tunnel, and Dual
Stack networks. Video traffic is loaded into the network for the respective graphs as shown in
Table 4.1, and the average number of packets successfully received or transmitted by the receiver
82

or transmitter channel per second is analysed. Figure 4.13(d) has the highest throughput because
it has the highest video quality or data traffic (15 frames/sec frame inter-arrival time and 34560
frame size). The throughput is measured on the 100BaseT link from the router to the Video server.

(b)

(a)

(c)

(d)

Fig. 4.14: Throughput with Video traffic only

4.3.5

Utilization Analysis of Video Traffic with no background traffic

Figure 4.15 shows the graphs of utilization collected for all the networks with only video traffic.
The utilization is measured in the same direction as the throughput in the previous section. This is

83

why the respective graphs of utilization are very much like those of throughput. It can be seen that
Figure 4.15(b) and (d) have higher utilizations because of a larger frame size.

(a)

(b)

(d)

(c)
Fig. 4.15: Utilization with Video traffic only

84

4.4

Simple Network Simulation of Networks with Video, FTP and

Database traffic

This section analyses the simple network when Video, FTP and Database traffic is loaded. Only
Video traffic is varied according to Table 4.1 above. FTP and Database traffic are configured with
the same values for all the cases. Database traffic is configured with a transaction inter-arrival time
of 2000 seconds, a transaction size of 1 MB, and the types of service is set to background. The
FTP traffic is configured with an inter-request time of 2000 seconds and the type of service is set
to best effort. All simulations are done for a period of 30 minutes.

4.4.1

Ethernet Delay Analysis of Video Packets with background traffic

This section shows the graphs of Ethernet Delay with FTP and Database traffic set to constant
values while video traffic is varied using the same parameters in table 4.1. When compared to the
respective graphs of Figure 4.11(a) to (d), it can be noticed that there is a slight difference in
Ethernet delay between the four networks measured. This is as a result of the presence of
background traffic. Figure 4.16 shows that IPv4 has a lower Ethernet delay curve in all cases.

(a)

(b)
85

(c)
Fig. 4.16: Utilization with Video Packets and background traffic

4.4.2

(d)

Packet Delay Variation Analysis of Video Packets with background

traffic

Figure 4.17 shows the comparison between the packet delay variation of IPv4, IPv6, 6to4 Tunnel
and Dual Stack networks in the presence of background traffic. The PDV of IPv6 and IPv4 can be
seen to have a lower curve for the cases of Figure 4.17(a) and (c) (with frame sizes of 17280 bytes)
while IPv6 has the lowest PDV curve as seen in the cases of Figure 4.17(b) and (d) (with frame
sizes of 34560 bytes).

86

(b)

(a)

(d)

(c)

Fig. 4.17: Packet Delay Variation with Video Packets and background traffic

4.4.3

Packet Endto-End Delay Variation Analysis of Video Packets with

background traffic

This section shows the statistical graph of packet end-to-end delay for the four networks being
measured in the presence of background traffic. Video data is loaded into the network using the
parameters of Table 4.1. The graphs for this section are the same as those in Figure 4.13.

87

4.4.4

Throughput Analysis of Video Traffic with background traffic

Figure 4.18 shows the comparison between the throughputs of IPv4, IPv6, 6to4 Tunnel and Dual
Stack networks in the presence of background traffic. Video traffic is loaded into the network for
the respective graphs as shown in Table 4.1, and the throughput is analysed. Figure 4.18(d) has the
highest throughput because it has the highest video quality or data traffic (15 frames/sec frame
inter-arrival time and 34560 bytes frame size). The throughput is measured on the 100BaseT link
from the router to the Video server. There is a slight difference in the throughputs of the respective
networks with and without background traffic.

(a)

(b)

(d)

(c)
88

Fig. 4.18: Throughput with Video Packets and background traffic

4.4.5

Utilization Analysis of Video Traffic with background traffic

Figure 4.19 shows the graphs of utilization collected for all the networks with video, FTP and
Database traffic. The utilization is measured in the same direction as the throughput in the previous
section. This is why the respective graphs of utilization are very much like those of throughput. It
can be seen that Figure 4.15(b) and (d) have higher utilizations because of a larger frame size.
There is a slight difference in the throughputs of the respective networks with and without
background traffic.

(a)

(b)

(c)
Fig. 4.19: Utilization with Video Packets and background traffic
89

(d)