Você está na página 1de 104

Into the future with IPv4 or IPv6?

Kevin F. Doyle BA (Psychology & Information Technology)


email: kfrdoyle@gmail.com
web: ie.linkedin.com/in/kdcod

Discipline of Information Technology
College of Engineering and Informatics
NUI Galway
Ireland
2010

Abstract
In the early 1990s the Internet experienced exponential growth; Internet Protocol version 4
(IPv4) address depletion was first recognised as presenting a serious strategic problem.
Currently the Internet is built on a 32 bit addressing scheme, this allows for a maximum of
4,294,967,296 unique IPv4 addresses to exist, however the number of devices requesting an
IPv4 address will shortly exceed the number of IPv4 addresses available. To remedy this and
other IPv4 issues IP version 6 (IPv6) was conceived and developed. IPv6 boasts a 128 bit
addressing scheme which can cater for up to 3.4x10
38
IP addresses. IPv6 is being offered as a
fix-all solution for IPv4 issues; however the market is slow to adopt IPv6. Using a literature
review, interviews and a case study based on HEAnet and NUIG-ISS this thesis examined the
technical and commercial pros and cons of IPv4 and IPv6. Results revealed that although
IPv4 is a very robust protocol, IPv6 surpasses IPv4 in orders of magnitude; from technical,
innovation and strategic perspectives there can be no doubt that IPv6 is the Internet Protocol
of the future.












Acknowledgements
I would like to thank the following people for answering the many questions I had
during the development of this thesis. A special thank you goes to my thesis supervisor Dr.
Hugh Melvin who provided a structured environment in which I had to attain bi-weekly
goals. I would also like to thank the following people Brian Nisbet (HEAnet), Gareth Eason
(HEAnet), Mike Norris (HEAnet), Tom Regan (NUIG ISS) and Will McDermott (HEAnet).
Finally I would like to thank my family (Frank, J oan, Susanne, J ohn and Barbara), and my
friends for providing support when needed.













Dedication
This work is dedicated to my parents Frank & J oan Doyle.
TABLE OF CONTENTS
PAGE
CHAPTER 1 - INTRODUCTION
1.0 Thesis Topic - Internet Protocol Version 4 & 6
1.1 Chapter Summary
CHAPTER 2 - RESEARCH APPROACH AND RATIONALE
2.0 Introduction
2.1 Literature Review Rationale
2.2 Literature Analysis Rationale
2.3 Case Study Rationale
2.4 Questionnaire Rationale
2.5 Research Hypothesis
2.6 Chapter Summary
CHAPTER 3 - LITERATURE REVIEW
3.0 Introduction
3.1 Origins of the Internet and Internet Protocol
3.2 The OSI 7-Layer Reference Model
3.21 Layer 1(Physical)
3.22 Layer 2 (Data Link)
3.23 Layer 3 (Network)
3.24 Layer 4 (Transport)
3.25 Layer 5 (Session)
3.26 Layer 6 (Presentation)
3.27 Layer 7 (Application)
3.3 Internet Protocol Version 4 (IPv4)
1
1
2
3
3
3
3
4
4
4
6
7
7
7
8
9
9
10
11
11
12
12
12
PAGE
3.31 IPv4 Addressing
3.32 IPv4 Address Classification
3.33 IPv4 Encapsulation & Formatting
3.34 IPv4 Datagram Size
3.35 IPv4 Maximum Transmission Unit (MTU)
3.36 IPv4 Fragmentation
3.37 IPv4 Delivery & Routing
3.38 IPv4 Multicasting
3.4 Internet Protocol Version 6 (IPv6)
3.41 IPv6 Addressing
3.42 IPv6 Address Classification
3.43 IPv6 Encapsulation & Formatting
3.44 IPv6 Datagram Size
3.45 IPv6 Maximum Transmission Unit (MTU)
3.46 IPv6 Fragmentation
3.47 IPv6 Delivery & Routing
3.48 IPv6 Multicast
3.5 Future Proofing IPv4
3.51 IPv4 Sub-netting or Fixed-Length Subnet Masks (FLSM)
3.52 IPv4 Variable Length Subnet Mask (VLSM)
3.53 IPv4 Classless Inter-Domain Routing (CIDR)
3.54 Network Address Translation (NAT)
3.55 Network Address, Port Translation (NAPT)
3.6 Parallel Internets IPv4 & IPv6
13
13
13
15
15
16
17
18
19
19
19
20
22
23
23
23
24
25
25
26
26
27
28
29
PAGE
3.61 Dual Stack IPv4 & IPv6
3.62 IPv6 Tunnelling
3.63 Transmission of IPv6 over IPv4 Domains (6over4)
3.64 Transmission of IPv6 Domains to IPv4 Clouds (6to4)
3.65 ISATAP Intra-Site Automatic Tunnel Addressing Protocol
3.66 Teredo Tunnelling
3.7 Mobile IP
3.71 Mobile IPv4
3.72 Mobile IPv6
3.8 Chapter Summary
CHAPTER 4 - LITERATURE ANALYSIS
4.0 Introduction
4.1 Throughput
4.2 Round Trip Time, J itter & Packet Loss Rate
4.3 Performance & Operating System (OS) Dependence
4.4 Application Performance (FTP, HTTP, VOIP, IPSec)
4.5 Scalability
4.6 Comparative Summary of Literature Review and Literature Analysis
4.7 Chapter Summary
CHAPTER 5 - CASE STUDY
5.0 Introduction
5.1 HEAnet
5.2 NUIG ISS
5.3 Chapter Summary
29
30
30
31
31
32
32
32
34
37
38
38
38
40
43
46
47
48
49
50
50
50
55
56
PAGE
CHAPTER 6 - QUESTIONNAIRE AND INTERVIEW DESIGN
6.0 Introduction
6.1 PESTEL
6.2 SWOT
6.3 BCP
6.4 Questionnaire Structure
6.5 Interview Structure
6.6 Chapter Summary
CHAPTER 7 - RESULTS AND ANALYSIS
7.0 Introduction
7.1 Literature Review Analysis
7.2 Literature Analysis (Analysis)
7.3 Questionnaire Analysis
7.4 Case Study Analysis
7.5 Summary of Questionnaire Results
7.6 Final Result
CHAPTER 8 - CONCLUSIONS
8.0 Final Conclusion
8.1 Results in Context
8.2 Identifying Future Work
References
APPENDICES
Appendix A Questionnaire to Gareth Eason of HEAnet
Appendix B Questionnaire to Tom Regan of NUIG-ISS
58
58
58
58
59
59
60
60
62
62
62
62
62
64
64
67
68
68
69
71
72
76
76
84
PAGE
Appendix C Thesis Process Evaluation
Appendix D - List of Figures
Appendix E - List of Abbreviations
89
91
92
P age | 1

CHAPTER 1 - INTRODUCTION
1.0 Thesis Topic - Internet Protocol Version 4 & 6
This thesis is all about Internet Protocol where IP is perhaps singly the most important
protocol that drives the Internet as we know it. Princeton (2010) defines a protocol as a set of
rules determining the format and transmission of data (http://wordnetweb.princeton.edu). On
the Internet today there are two versions of this protocol in operation, versions 4 and 6 or
IPv4 and IPv6 respectfully. Every device connected to the Internet requires a unique
identifier or IP address. Currently IPv4 is suffering from a serious lack of IP addresses driven
by an unprecedented and unpredicted number of new electronic devices connecting to the
Internet and requesting an IP address. IPv4 is capable of delivering a technical maximum of
4,294,967,296 IP addresses and currently there are approximately 0.5% of these IP addresses
remaining ("Driving IPv6 Deployment," 2010). In 1996 the Internet Engineering Task Force
(IETF) published the specification of IPv6; this new protocol was designed to deliver
3.4x10
38
IP addresses, an almost limitless supply for generations of Internet users to come.
Interestingly organisations have been slow to adopt this new IPv6 for many reasons
including but not limited to the following; IT strategy, technical experience, education,
financial restraints, immature technology, lack of consumer demand and lack of vendor
support. There is a lot of anxiety surrounding the adoption of this technology when you
consider that organisations IT and network infrastructure is built on a system (IPv4) that
works perfectly well for now, so why should they try to fix it if it doesnt appear to be
broken? This thesis aims to find out what organisations should do now, stay with IPv4 or bite
the bullet and adopt IPv6.
The remainder of the thesis is structured as follows. Chapter 1 gives a brief introduction
to the thesis topic. Chapter 2 describes the research approach and explains the rationale
behind the literature review; literature analysis, questionnaire and case study. This is then
P age | 2

followed by the research hypothesis. Chapter 3 is the literature review covering the core
topics of IPv4 and IPv6. Chapter 4 covers the literature analysis. Chapter 5 is the case study
which is based on HEAnet and NUIG-(ISS). Chapter 6 explains the design and tools used in
the questionnaire and pre-structured interview. Chapter 7 analyses the results of the literature
review; literature analysis and questionnaire. In the final chapter, Chapter 8, conclusions are
drawn and the results are examined in a wider context. The remaining sections are the
reference section; questionnaire results are in appendix A and B, a personal evaluation of the
process I went through to complete this thesis is given in appendix C, a list of figures and
abbreviations comprise appendix D and E respectfully.
1.1 Chapter Summary
This chapter provided a basic introduction to the core issues dealt with in this thesis. A
brief description of each chapter was also given to outline the structure of the thesis. In order
to derive scientific results and establish if IPv4 or IPv6 is the better protocol a research
method must be established, details of this methodology will be outlined in the following
chapter, Research Approach and Rationale.













P age | 3

CHAPTER 2 - RESEARCH APPROACH AND RATIONALE
2.0 Introduction
In this chapter a description of the tools used in the research approach is given. There
are 5 tools used in this approach, the first is the literature review followed by the literature
analysis, case study, questionnaire and finally the research hypothesis.
2.1 Literature Review Rationale
The Literature review details the various core technologies in use around the domain of
Network Engineering. It first presents the OSI 7-layer model, which shows Internet Protocol
in the context of other network services and technologies. It details hard technical facts on
IPv4 and IPv6 and non judgmental comparisons between the two protocols. Given that IPv6
is designed to supplant IPv4 an extra chapter Future Proofing IPv4 outlines how IPv4 is not
broken and will still compete with IPv6 for some time to come. As such, even if IPv6
succeeds there will be a need for a transition period that will be created if and when
organisations move en-mass to IPv6; this is covered in the chapter on Parallel Internets
where engineers have developed multiple communications protocols to cater for a diverse
range of site requirements. The Literature Review finishes with a brief presentation on
Mobile IP and explains some simple differences (in an otherwise extremely complex system)
that exist between the Mobile variants of IPv4 and IPv6. It is worthwhile to note that Mobile
IP is by an order of magnitude more complicated than traditional non-Mobile IP and as such
the treatment given to Mobile IP in this thesis is quite superficial.
2.2 Literature Analysis Rationale
To differentiate a literature review from a literature analysis we can turn to
(Berndtsson, Hansson, Olsson, & Lundell, 2008) who define it as follows: By literature
analysis we mean a systematic examination of a problem, by means of an analysis of
published sources, undertaken with a specific purpose in mind... our use of the term
P age | 4

literature analysis should not be confused with (literature) review (p. 58). The literature
analysis undertaken in this thesis provided interesting background material but more
importantly it helped to extract valid criteria by which a comparison could be made between
IPv4 and IPv6. Having this comparative data also helped generate questions that eventually
became part of the questionnaire that was administered in the pre-structured interview.
2.3 Case Study Rationale
(Berndtsson, et al., 2008) define a case study as: a study project... undertaken as an in
depth exploration of a phenomenon in its natural setting (p. 62). The case studies chosen for
this thesis turned out to be very interesting and informative. Both NUIG-ISS and HEAnet
were selected for this case study; both of these organisations provide similar services, that
being computer network connectivity and ancillary services. Having a case study will help in
results analysis when data from the literature analysis and review can be qualified by real
world data from the case study and questionnaire.
2.4 Questionnaire Rationale
The questionnaire was delivered in the form of a pre-structured interview and was
chosen as a method to gain real world data from the two interviewees who participated in this
survey. (Berndtsson, et al., 2008) states that this interview technique is: ... characterised by a
fixed set of questions... in its pure form, it does not allow adding or deleting questions
depending on the replies. With respect to repeatability, it has an obvious advantage over the
open interview (p. 60); the list of questions that comprise the questionnaire are available in
appendix A.
2.5 Research Hypothesis
When an electronic device connects to the internet it requires an IP address. Currently
the software designed to implement this IP addressing scheme is at version 4. The original
specification for IP version 4 allotted 32 bits of memory to the IP address size however a 32
P age | 5

bit address can only supply 4,294,967,296 unique IP addresses; this number is based on the
calculation of raising 2 to the power of 32 (2
32
). As it stands there are 240 million IPv4
addresses remaining ("Driving IPv6 Deployment," 2010). The latest implementation of IP
software is at version 6. IPv6 allots 128 bits of memory to the IP address size allowing for
3.4x10
38
(2
128
) unique IP addresses to exist.
Judgment Day or Global IPv4 address exhaustion is predicted to occur in
2013("Driving IPv6 Deployment," 2010). It would be difficult to predict all eventualities
when this event occurs but some of the situations that may occur include:
(1) Hoarding of the final block of IP addresses for selling at extortionate rates.
(2) The Internet stops growing; increased use of NAT will striate the Internet even
more and slow down Internet traffic.
(3) Increased traffic congestion.
(4) Increased threat from computer viruses, because calculating what IP addresses to
attack next is no longer required due to every IP address being a valid host
(5) Threats to business and innovation.
In 1996 the IPv6 specification was published. IPv6 was designed to be a long term
solution to the address exhaustion problem. At the same time a short term solution called
Network Address Translation (NAT) was developed to help prolong the life of the remaining
IPv4 address pool. Since then the adoption of NAT has become so widespread and complete
that NAT has now become a dominant technology and is a threat to the adoption of IPv6 due
to the lower costs associated with implementing NAT as opposed to implementing IPv6.
During the course of my research I spent 6 months working at the Irish National
Research and Education Network, HEAnet Ltd which is based in Dublin. My time with
HEAnet coincided with their ongoing rollout of their IPv6 network. It was during the
development of a strategic proposal for HEAnet that I became interested in the IPv4/IPv6
P age | 6

issue. My early research revealed that cost would be a prohibitive factor in the rate at which
organisations adopt IPv6. Subsequent research revealed that IPv6 has a lot more to offer than
just limitless IP addresses, including improved security, connectivity and throughput.
However product vendors and their customers are slow to adopt IPv6 enabled products and
services; the current economic climate is also not helping.
Objectively this thesis will go to the source in relation to technical specifics on IPv4
and IPv6 with the Internet Engineering Task Force (IETF) being the main sources. The IETF
publish all of their technical specifications for both versions of IP in their Request For
Comment (RFC) database. A review of academic literature is then carried out and finally an
extensive questionnaire will be given to Gareth Eason of HEAnet and Tom Regan of the
NUIG-(ISS) department. The key outcome will be to discover what Internet Protocol should
be adopted, IPv4 or IPv6 to preserve and uphold the stability of the Internet as we know it.
2.6 Chapter Summary
This chapter outlined the research methodology developed in this thesis. The beginning
of this research process commences in the following chapter the Literature Review, where
IPv4, IPv6 and associated technologies are described.









P age | 7

CHAPTER 3 - LITERATURE REVIEW
3.0 Introduction
In order to understand the technology of Internet Protocol, this chapter reviews this
protocol in a historical context and it details how far reaching the effects of Internet Protocol
can be, given the intrinsic relationship between Internet Protocol and the many software
programs and Internet services people use on the Internet every day.
3.1 Origins of the Internet and Internet Protocol
After the launch of the Russian Sputnik satellite in 1957 the U.S. Defence Advanced
Research Projects Agency (DARPA) established a project to promote research cooperation
between universities, this project became known as Advanced Research Project Agency
NETwork (ARPANET) (Hafner & Lyon, 1996). In 1958 under the initial directorship of Roy
J ohnson ARPANET went into business. Their goal was to link together university computing
resources over the existing North American national telephone network. After ten years of
intense research and development two Interface Message Processors (IMPs) were installed,
one at the University of California Los Angeles (UCLA) and the other at Stanford Research
Institute (SRI), communications between these two devices commenced on October 1, 1969
(Hafner & Lyon, 1996).
In 1970 the Network Working Group (NWG) a project team within ARPANET
produced the first host-to-host communications protocol called the Network Control Protocol
(NCP). By 1978 this protocol had evolved in specification and complexity and became
known as the Transmission Control Protocol (TCP). ARPANET was then able to facilitate
Telnet and File Transfer sessions. In the same year during a meeting at the University of
Southern Californias Information Sciences Institute (ISI) a decision was taken to split TCP
into two logical groupings. TCP would be charged with the control, sequencing and error
handling of data packets and Internet Protocol would be used to route IP packets through
P age | 8

each network node. This decision resulted in the creation of the now familiar acronym
Transmission Control Protocol / Internet Protocol (TCP/IP) (Hafner & Lyon, 1996).
Once vendors got wind of the ARPANET project and realised the potential monetary
gains to be had they each started to develop their own proprietary network protocols.
Computer industry players such as IBM, Apple, Novell and DEC each produced their own
implementation of TCP/IP (Hafner & Lyon, 1996). With a view to preventing the striation of
the Internet with a plethora of proprietary network protocols the International Organisation
for Standards (ISO) and the International Telecommunications Union (ITU-T) co-developed
the Open System Interconnection (OSI) reference model (ITU-T, 1994). The OSI model is
the de facto reference model for TCP/IP.
3.2 The OSI 7-Layer Reference Model

Figure: 1 The OSI model showing logical and actual data flows
P age | 9

The OSI reference model is comprised of the following 7 layers: Physical, Data Link,
Network, Transport, Session, Presentation and Application. This model is illustrated in figure
1 where the OSI 7 layer model is a metaphor for the TCP/IP communications stack. Data
flows through each layer in the IP stack as it travels from an application on host A to an
application on host B.
3.21 Layer 1 (Physical)
Layer 1 facilitates the movement of serial binary data over a physical link that joins two
or more network nodes. The physical link can take the form of electrical signals on a copper
cable, pulses of light on a fibre-optic cable or pulses of electromagnetic radiation travelling
between radio transceivers.
3.22 Layer 2 (Data Link)
There are many data link layer protocols such as Digital Subscriber Line (DSL),
Ethernet and Point to Point Protocol (PPP). For simplicity this thesis will only talk about the
Ethernet protocol. At layer 2 the OSI specification describes how network nodes should
format their data into frames for transmission and reception. An astute account of how this
mechanism works in an Ethernet network is given by (Anttalainen, 2003):
The data link layer at the transmitting node builds the frames and sends them to the
node on the other end of the Ethernet medium via the physical layer. The data link layer
at the receiving node receives the frames, checks if these frames are error free, and then
delivers error-free frames to the network layer. The data link layer at the receiver may
send acknowledgment of error-free frames to the transmitting node. The transmitter
may retransmit the frame if no acknowledgment is received within a certain time
period. Note that this procedure occurs between each pair of nodes on the network. (p.
245)

A
of the E
commu
address
the form
the Fram
transmi
frame.
A
point co
demand
vast dis
frame re
payload
IP conn
T
fragmen
address
32-bit I
At the heart
Ethernet fram
unicating tra
s of the rece
mat of the d
me Check S
ission errors
F
At this stage
ommunicati
d that inform
stances. Thi
eaches its d
d section, th
nectivity is e
3.23 Layer
he Network
ntation of IP
s size. (Spur
P address a
of Ethernet
me as follow
ansceivers, (
eiver and sen
data carried i
Sequence is
s . Figure 2
Figure: 2 Th
it is import
ion between
mation be in
s situation i
destination t
he IP packet
established.
3 (Network
k layer of th
P packets. I
rgeon, 2000
and 48-bit E
t is the Ethe
ws: (1) The
(2) the 48 b
nder respect
in the paylo
used to car
shows the l
he Ethernet V
tant to unde
n two netwo
ntelligently
is handled b
the receiving
t is then pas

k)
he OSI mod
Pv4 uses an
0) points out
Ethernet add
ernet frame;
Preamble f
it Destinatio
tfully, (3) th
oad field, (4
rry the resul
latest implem
V2 frame S
erstand that
ork nodes at
routed throu
by layer 3, th
g node extr
ssed up to L
el is respon
n IP address
t that ...in a
dress. Howe
(Spurgeon
field is used
on and Sour
he Type/Ve
4) the actual
lt of the FCS
mentation (
Source: (Spu
layer 1 and
t any one tim
ugh many in
he Network
acts the IP p
Layer 3 the N
nsible for for
s size of 32
a given com
ver it doesn
, 2000) desc
d to synchro
rce address
ersion field i
l Payload D
S to aid in d
(Version 2)
urgeon, 200
layer 2 onl
me, practica
ntermediary
k layer. Whe
packet from
Network lay
rmatting, ad
bits while I
mputer it is a
n't know the
P a
cribes the e
onise
are the Eth
is used to in
ata and fina
detection of
of the Ethe
00)
ly facilitate
al situations
y nodes and
en an Ethern
m the frames
yer. This is w
ddressing an
IPv6 uses a
aware of (it
e Ethernet
ge | 10
lements
hernet
ndicate
ally (5)
f
rnet

point to
s
d over
net
s
where
nd
128 bit
s own)
P age | 11

addresses of the other stations on the network ... when first send(ing) a packet (p. 37).
(Postel, 1981b) points out that in an Ethernet system the sending and receiving stations must
know each others Ethernet address. For an IPv4 node to discover the Ethernet address of
neighbouring IPv4 nodes the Address Resolution Protocol (ARP) is used. When connecting
to the Ethernet for the first time a node will send out an IPv4 address request to a special IPv4
broadcast address requesting the Ethernet address of a target node, the intended node will be
the only one to reply to the request, the requested IPv4 address and the Ethernet address are
sent back to the requesting node. This is how IPv4 connectivity is established.
(Narten, Nordmark, Simpson, & Soliman, 2007) articulate that for an IPv6 node to
discover the Ethernet address of neighbouring IPv6 nodes the Neighbour Discovery Protocol
(NDP) is used; when connected to the Ethernet for the first time an IPv6 node will send out a
Router Advertisement (RA) message until link-layer addresses of other connected nodes are
learned
3.24 Layer 4 (Transport)
The previous three OSI layers examined connectionless unreliable service between IP
nodes. (Comer, 1999) articulates that layer 4, the transport layer builds reliability into the OSI
system by providing the following services to the upper layers of the OSI model Connection
Orientation, Point-to-Point Communication, Complete Reliability, Full Duplex
Communication, Stream Interface, Reliable Connection Start-up and Graceful connection
Shutdown An example of a protocol in this layer include Transmission Control Protocol
(TCP) (p. 310).
3.25 Layer 5 (Session)
Layer 5 the session layer is all about allowing computer applications to communicate
with each other over the network. (Kozierok, 2005) defines OSI layer 5 as having being
designed to allow devices to establish and manage sessions. In general terms, a session is a
P age | 12

persistent logical linking of two software application processes to allow them to exchange
data over a prolonged period of time (p. 177).
3.26 Layer 6 (Presentation)
Layer 6 the Presentation layer of the OSI model is charged specifically with ensuring
that software applications on different types of computers on the network can communicate
with each other transparently even if they represent information in different formats such as
American Standard Code for Information Interchange (ASCII) or Extended Binary Coded
Decimal Interchange Code (EBCDIC). (Kozierok, 2005) highlights three core responsibilities
of the presentation layer including translation, compression/decompression and
encryption/decryption... Secure Socket Layer (SSL) encryption of connections to secure
websites is carried out in the presentation layer (p. 179). Any function that the presentation
layer carries out is done when requested by the upper most layer in the OSI model the
Application layer.
3.27 Layer 7 (Application)
Layer 7 the Application layer is where many software applications provide a human
interface or Graphical User Interface (GUI) to the services offered at this layer. When we
look at web pages using a web browser such as Internet Explorer we are using the Hyper Text
Transfer Protocol (HTTP), a service offered by the application layer. Other examples of layer
7 protocols include Domain Name System (DNS) and File Transfer Protocol (FTP).
3.3 Internet Protocol Version 4 (IPv4)
Herein specifies the United States Department of Defence Standard Internet Protocol.
This specification is based on six earlier editions of the Advanced Research Project Agency
(ARPA) Internet Protocol (Postel, 1981b, p. iii).


P age | 13

3.31 IPv4 Addressing
An IPv4 address indicates where a particular network node is. Each IPv4 node has a 32
bit binary address, an example being 01011001110011001111001011011111. To make these
addresses more readable the binary numbers are converted to base ten and are also separated
into octets by dots, an example being 89.204.242.223. Having a 32 bit IPv4 address size
allows up to unique IPv4 addresses to exist on the Internet.
3.32 IPv4 Address Classification
To create an IPv4 address space hierarchy, IPv4 addresses have a network and host
address encoded into a single address. This technique divides the 32 bit address along three
specified boundaries; these divisions occur at the 24 bit, 16 bit and 8 bit sections of the IPv4
address. These divisions evolved into classes of addresses that are represented clearly in
figure 3.

Figure 3 IPv4 address hierarchy Source: (Postel, 1981a; Sportack, 2002; Wegner & Rockell,
2000)
3.33 IPv4 Encapsulation & Formatting
Starting with OSI layer 2, the Data Link layer and focusing on the Ethernet system,
figure 4 illustrates how an Ethernet frame encapsulates an IP packet in its payload section.
The IP packet in turn encapsulates a TCP segment which in turn encapsulates data from layer
5, 6 and 7.
P age | 14


Figure 4 An Ethernet frame encapsulating Layer 3 and above Source: (Spurgeon, 2000)
According to (Spurgeon, 2000) encapsulation: is the mechanism that allows
independent systems to work together, such as network protocols and Ethernet LANs (p.
36).

Figure 5 The IPv4 header Source: RFC 791
The IPv4 packet header is comprised of 15 sections which are shown in figure 5. Each
section has the following function as set out by (Postel, 1981b):
The 4 bit Version field indicates the format of the internet header. The 4 bit Internet
Header Length (IHL) indicates the length of the packet header and thus points to the
beginning of the data. The 8 bit Type of Service field provides an indication of the
abstract parameters of the quality of service desired. The 16 bit Total Length field is the
length of the datagram in totality. The 16 bit Identification field is an identifying value
assigned by the sender to aid in assembling the fragments of a datagram. The 3 bit
Flags field facilitates various Control Flags. The 13 bit Fragment Offset field indicates
where in the datagram this fragment belongs. The 8 bit Time to Live field indicates the
maximum time the datagram is allowed to remain in the internet. The 8 bit Protocol
field indicates the next level protocol used in the data portion of the internet datagram.
P age | 15

The 16 bit Header Checksum field is a checksum on the header only. Since some
header fields change (e.g., time to live), this is recomputed and verified at each point
that the internet header is processed. The 32 bit Source Address is used to identify the
sending station at the IP layer. The 32 bit Destination Address is used to identify the
receiving station at the IP layer. The Options field may appear or not in datagrams. (pp.
11-15)
3.34 IPv4 Datagram Size
As articulated in (Postel, 1981b) the smallest legal datagram size is 576 bytes and
additionally:
The number 576 is selected to allow a reasonable sized data block to be transmitted in
addition to the required header information. The largest datagram size that can be
accommodated is 65,535 bytes. The maximum internet header size is 60 bytes, and a
typical internet header is 20 bytes long, allowing a margin for headers of higher level
protocols. (p. 12)
3.35 IPv4 Maximum Transmission Unit (MTU)
Given that an IPv4 datagram can be encapsulated in a multitude of Data Link layer
technologies such as Ethernet, FDDI and Token Ring, the Maximum Transmission Unit or
maximum datagram size will vary depending on the OSI Layer 2 transmission technology.
(Parker & Siyan, 2002, p. 217) bring together a collection of MTUs and their associated
technologies as illustrated in figure 6.

Figur
A
of netw
be able
network
link. Th
A summ
W
fr
Fi
L
lo
in
ad
24
K
indepen
network
re 6 MTU s
3.36 IPv4 F
As IP packet
works each b
to be broke
k. These fra
his process i
mary of poin
When fragme
ragment onl
ield, More F
ength Field
ocation, rela
nternet ident
ddress, and
4)
Keeping in m
ndent entity
k routes; thi
size compar
Fragmentati
ts are sent o
built on a va
en into smal
agments then
is handled b
nts are taken
entation occ
ly. The field
Fragments F
d and Heade
ative to the b
tification fie
the protoco
mind that on
and can be
is concept is
isons of Lay
ion
out over the
ariety of Lay
ller parts to
n need to be
by the fragm
n from (Pos
curs, some o
ds which ma
Flag, Fragm
er Checksum
beginning o
eld (ID) is u
ol fields, to i
nce an IP pa
directed se
s called data
yer 2 techno
Internet the
yer 2 techno
overcome d
e reassembl
mentation m
stel, 1981b)
options are
ay be affect
ment Offset,
m... The Fra
of the origin
used togethe
identify dat
acket has be
eparately fro
agram indep
ologies Sou
ey will have
ologies, ther
different M
led in seque
mechanism in
illustrates h
copied, but
ted by fragm
Internet He
agment Offs
nal un-fragm
er with the
tagram fragm
een fragmen
om its sister
pendence as

urce: (Parke
e to traverse
refore an IP
TU sizes en
ence at the o
n IPv4.
how fragme
t others rem
mentation in
eader Lengt
set field iden
mented datag
source and
ments for re
nted each fra
r fragments
s outlined in
P a
er & Siyan,
e a diverse m
P packet nee
ncountered i
other end of
entation wo
main with the
nclude: Opti
th Field, To
ntifies the fr
gram... The
destination
eassembly.
agment beco
over differe
n (Postel, 19
ge | 16
2002)
mixture
eds to
in each
f the
orks:
e first
ions
otal
fragment
e
(pp. 23-
omes an
ent
981b).
P age | 17

3.37 IPv4 Delivery & Routing
To quote (Hall, 2000) IPv4 is responsible only for getting datagrams from one host to
another, one network at a time (p. 32). Explaining the delivery and routing process of IPv4
is best done through an example. Figure 7 depicts two separate IP networks joined via a
router. Each network has two IPv4 enabled hosts. Computers A and C have direct
connections to each other eliminating the need to route data through the router, the same goes
for computers B and D. If communication is required between network 1 and network 2 then
the router acts as an intermediary between the communicating parties.

Figure 7 IP Routing and Delivery between networks
Each host on the network keeps track of simple routes to neighbouring hosts in a file
called a route table. In order for IPv4 to discover the Ethernet address of a remote node the
Address Resolution Protocol (ARP) is used. Once Layer 2 & 3 connectivity is established a
small list of IPv4 addresses and their corresponding Ethernet address are stored on each host
in the ARP cache (Hall, 2000).


P age | 18

3.38 IPv4 Multicasting
IP multicasting is a specialised form of broadcasting where IP packets are sent to a
select number of hosts who have indicated they want to receive multicast transmissions. IP
multicasting is built on a special range of IP addresses; according to the Internet Assigned
Numbers Authority (IANA) the multicast address space occupies the range 224.0.0.0 to
239.255.255.255. (Goncalves & Niles, 1999) articulate the following points about IP
multicasting:
In a unicast environment a node only has the ability to send to one other node at a time.
In a multicast environment, a node can efficiently send a single packet of information to
multiple destination nodes in one operation. A node's operating system and TCP/IP
stack must support IP multicasting for the node to participate in multicastingIP
multicasting... creates a single stream of data to which users subscribe... IP Multicast
reduces bandwidth demands by carrying only one instance of the data to multiple
destinations (pp. 92-120)
For IP multicasting to work, routers, switches and hosts must be running the Internet
Group Management Protocol (IGMP). (Fenner, 1997) describes how this protocol works:
IGMP is used by IP hosts to report their multicast group memberships to neighbouring
multicast routers. Multicast routers use IGMP to learn which groups have members on
each of their attached physical networks. A multicast router (in turn) keeps a list of
multicast group memberships for each attached network. (pp. 1-3)
This concludes the section on IPv4. The next chapter covers a protocol that started
development in 1996 and as of now the year 2010 organisations have already deployed this
new version of Internet Protocol called IPv6. This protocol has a lot in common with IPv4
but it also brings new features that are still under analysis by engineers and scientists.

P age | 19

3.4 Internet Protocol Version 6 (IPv6)
Here in specifies an Internet standards track protocol for the Internet community, and
requests discussion and suggestions for improvements. Specifically version 6 of the Internet
Protocol (IPv6) is also sometimes referred to as IP Next Generation or IPng (Deering &
Hinden, 1998).
3.41 IPv6 Addressing
In IPv6, multiple IPv6 addresses can be assigned to a network interface; in turn
multiple interfaces can be part of a network node. Each IPv6 address has a 128 bit binary
address, an example being 100000000000011110111000011000100000000000000000
000000000000000011000001000000011101101100111001. To represent these addresses in
a manageable form they are converted to hexadecimal and are also separated into eight 16 bit
blocks separated by colons; converting the binary address above produces the following IPv6
address 2001:770:18:2::c101:db39. Due to its 128 bit address length the IPv6 protocol is able
to provide

unique addresses.
3.42 IPv6 Address Classification

Figure 8 IPv6 unicast address allocation Source: (Hinden & Deering, 2006)
The first type of IPv6 unicast addressing is called Link-Local unicast addressing; this
type of IPv6 address is assigned to a physical interface at Layer 3 (Hinden & Deering, 2006)
present the following points and figure 8 to note on IPv6 Link-Local unicast addressing:
(A Link-Local unicast address is an) identifier for a single interface. All interfaces
are required to have at least one Link-Local unicast address. A single interface may

al
L
su
pr
ad
fi
in
T
of IPv6
hierarch
an ident
address
lso have mu
ocal addres
uch as autom
resent Ro
ddresses to
gure 9) w
nterface. (pp
he next typ
packets an
hically-struc
tifier of a li
s of the inter
3.43 IPv6 E
Figu
Figure
Figure
ultiple IPv6
sses are desi
matic addre
outers must
other links
where the in
p. 5-11)
e of IPv6 ad
d illustrated
ctured) valu
nk within th
rface as out
Encapsulati
ure 11 IPv6
9 Link-loca
e 10 Global
addresses o
igned to be
ess configur
not forward
Link-Loc
nterface ID i
ddress is the
d in figure 1
ue assigned
he site, and
lined by (H
on and For
encapsulat
al unicast ad
l unicast add
of any type
used for ad
ation, neigh
d any packe
cal addresse
is (usually c
e global uni
10. The glob
to a site (a
the interfac
Hinden & De
rmatting
ion Source:
ddress Sour
dress Sourc
(unicast, an
ddressing on
hbour discov
ets with Lin
es have the
crafted) from
icast addres
bal routing p
cluster of su
ce ID is usu
eering, 2006
(Deering &
rce: (Hinden
e: (Hinden
nycast, and m
n a single lin
very, or wh
nk-Local sou
following f
m the MAC
ss used for e
prefix is a (
ubnets/links
ually crafted
6).
& Hinden, 1

n & Deering

& Deering,
P a
multicast)
nk for purpo
hen no route
urce or desti
format (as p
C address of
every day ro
typically
s), the subn
d from the M
1998)
g, 2006)
, 2006)
ge | 20
Link-
oses
ers are
ination
per
f the
outing
net ID is
MAC

P age | 21

IPv6 is encapsulated in Layer 2 in much the same way as IPv4; however the IPv6
header and optional header extensions take up more space, 20 bytes for IPv4 compared to 40
bytes for IPv6. Figure 11 illustrates a TCP segment encapsulated in an IPv6 packet in turn the
IPv6 packet is encapsulated in an Ethernet V2 frame.
A major difference between IPv4 and IPv6 is the structure and format of the IPv6
packet header; (Deering & Hinden, 1998) specification for the IPv6 header is as follows:
The 4 bit Version field contains the Internet Protocol version number, 4 or 6. The 8 bit
Traffic Class field enables a source to identify the desired delivery priority of its
packets, relative to other packets from the same source. The 20 bit Flow Label field is
used to tag a sequence of packets that should receive special treatment from routers.
The 16 bit Payload Length field indicates the length of the payload data including the
extension headers. The 8 bit Next Header field identifies the type of header
immediately after the IPv6 header. The 8 bit Hop Limit field is used to control how
many nodes a packet can pass through. The 128 bit Source Address field contains the
address of the originator of the packet and the 128 bit Destination Address contains the
address of the intended recipient of the packet. (p. 4)
The IPv6 header along with four currently specified extension headers are illustrated in
figure 12, where the specifics of the extension headers are defined by (Deering & Hinden,
1998) as follows:
The Hop-by-Hop Options header is used to carry optional information that must be
examined by every node along a packet's delivery path. The Hop-by-Hop Options
header is identified by a Next Header value of 0 in the IPv6 header The Destination
Options header is used to carry optional information that need be examined only by a
packet's destination node(s). The Destination Options header is identified by a Next
Header value of 60 in the immediately preceding header The Routing header is used
P age | 22

by an IPv6 source to list one or more intermediate nodes to be "visited" on the way to a
packet's destination. The Routing header is identified by a Next Header value of 43 in
the immediately preceding header The Fragment header is used by an IPv6 source to
send a packet larger than would fit in the path MTU to its destination. (Unlike IPv4,
fragmentation in IPv6 is performed only by source nodes, not by routers along a
packet's delivery path). The Fragment header is identified by a Next Header value of 44
in the immediately preceding header. (pp. 11-23)

Figure 12 IPv6 Header and Extension headers Source: (Deering & Hinden, 1998)
3.44 IPv6 Datagram Size
(Deering & Hinden, 1998) specify that IPv6 has a minimum datagram size of 1280
bytes. In Ethernet systems it is recommended that the minimum IPv6 datagram size be 1500
bytes. If IPv6 undergoes translation to IPv4 where the legal minimum datagram size is 576
bytes, IPv6 systems are allowed to reduce their payload size to 1232 bytes which allows
space for the 40 byte IPv6 header and 8 byte fragmentation header. Given that the payload
length field in the IPv6 header is 16 bits long it is capable of carrying up to 65,535 bytes of
data. (Borman, Deering, & Hinden, 1999) stipulate an addition to IPv6 called J umbo-grams;
these are packets with a payload larger than 65,535 bytes. J umbo-grams are achieved through
P age | 23

the use of an extension header that uses a 32 bit payload length field allowing the field to
address up to 4,294,967,295 bytes of data. Obviously different networking equipment
supports different datagram sizes so as data travels over links of varying capacity the
maximum throughput is determined by the Maximum Transmission Unit (MTU) of the entire
link.
3.45 IPv6 Maximum Transmission Unit (MTU)
(McCann, Deering, & Mogul, 1996) recommend that every link in an IPv6 internet
have an MTU of 1280 bytes and where data-grams may need to be encapsulated an MTU
configuration of 1500 bytes is recommended. If packets larger than the link MTU need to be
sent, packet fragmentation may be used but in the interests of optimum performance packet
fragmentation is very much discouraged in IPv6.
3.46 IPv6 Fragmentation
If and when fragmentation is required the fragmentation extension header is used (as
shown in figure 12) by an IPv6 source to send packets that are larger than the path MTU,
however unlike IPv4, fragmentation in IPv6 is performed only by source nodes, not by
routers along a packet's delivery path (Deering & Hinden, 1998).
3.47 IPv6 Delivery & Routing
The delivery and routing methodology in IPv6 is quite different from its predecessor
IPv4. When IPv6 nodes connect to the network for the first time they configure themselves
with a Link-local unicast address; they then instigate the Neighbour Discovery Protocol.
Nodes (hosts and routers) use Neighbour Discovery to determine the link-layer addresses
(Layer 2) for neighbours known to reside on attached links. Hosts also use Neighbour
Discovery to find neighbouring routers that are willing to forward packets on their behalf. As
previously discussed the IPv6 header contains a source address and a destination address,
IPv6 also makes use of a routing extension header that an IPv6 source can use to list one or
P age | 24

more intermediate nodes to be "visited" on the way to a packet's destination. All of this
addressing data is supplied and kept up to date by Neighbour Discovery Protocol (Deering &
Hinden, 1998; Narten, et al., 2007).
3.48 IPv6 Multicast

Figure 13 IPv6 Multicast address format Source: (Hinden & Deering, 2006)
There are three types of addressing in IPv6, unicast, anycast and multicast. Researchers
(Hinden & Deering, 2006) define anycast and multicast addressing as follows:
Anycast (is) an identifier for a set of interfaces (typically belonging to different nodes).
A packet sent to an anycast address is delivered to one of the interfaces identified by
that address (the "nearest" one, according to the routing protocols' measure of distance).
Multicast (is) an identifier for a set of interfaces (typically belonging to different
nodes). A packet sent to a multicast address is delivered to all interfaces identified by
that address. (p. 2)
IPv6 multicast addresses are in the following range FF00::/8, anycast addresses are
taken from the unicast address pool which includes every other address except ::/128,
::1/128, FF00::/8 and FE80::/10. Figure 13 shows the IPv6 multicast address format where a
group of Internet multicast servers could be assigned the group ID of 101Hex, resulting in an
address of the following format, FF0E:0:0:0:0:0:0:101 (Hinden & Deering, 2006). A final
point to note on IPv6 multicast is that it uses the Multicast Listener Discovery (MLD)
protocol which distinguishes it from IPv4 which uses IGMP.
This section described IPv6 a technology designed to supplant IPv4. During the
transition to IPv6 engineers developed two short term solutions to the IPv4 address depletion
P age | 25

issue, Classless Inter-Domain Routing (CIDR) and Network Address Translation (NAT).
These two technologies were designed to prolong the life of the IPv4 address space however
these technologies have gained first mover advantage over IPv6. These technologies are now
hindering the deployment of IPv6.
3.5 Future Proofing IPv4
In 1996 the development of IPv6 began with the view that this technology would be a
long term solution to the IPv4 address depletion problem. As a stop gap short term solution
Variable Length Subnet Masking (VLSM), Classless Inter-Domain Routing (CIDR) and
Network Address Translation (NAT) were developed to help slow the depletion of IPv4
addresses. These technologies have gone a long way to future proofing IPv4 even in the face
of what is perceived and engineered to be a better protocol, IPv6.
3.51 IPv4 Sub-netting or Fixed-Length Subnet Masks (FLSM)
From the outset it is important to distinguish between a network mask and a sub-
network mask. A network mask is used to identify the network portion of an IPv4 address;
there are three IPv4 network masks (255.0.0.0), (255.255.0.0) and (255.255.255.0) which are
applied to /8, /16 and /24 (CIDR notation) networks respectfully. Network masks must also
occur along octet boundaries of the IPv4 address.
A sub-network mask is a 32-bit binary number; a sub-network mask is structurally
similar to an IP address however a sub-network mask is not routable, nor does it have to be
unique. The mask is used to tell end systems in the network how many bits of the IP address
are used for network and sub-network identification. These bits are called the extended
network prefix. The remaining bits identify the hosts within the sub-network. The bits of the
extended network prefix that identify the network mask and the sub-network mask are set to
1s and the host bits are set to 0s. For example, a dotted-binary mask of
(11111111.11111111.11111111.11000000) equates to (255.255.255.192) in dotted-decimal
P age | 26

notation (Parker & Siyan, 2002; Sportack, 2002). Fixed Length Subnet Masking still
produces wastage of IPv4 addresses; a further refinement of FLSM is covered in the next
section.
3.52 IPv4 Variable Length Subnet Mask (VLSM)
To reduce IPv4 address wastage (Parker & Siyan, 2002) articulate that instead of using
one subnet mask to carve up an address space, one should use many subnet masks all of
varying sizes (p. 78). To illustrate this point, consider an organisation that has two separate
subnets each with a 22 bit extended network prefix; the organisation wants to join these
networks via a third point-to-point network. Applying a 22 bit FLSM to the point-to-point
link would be quite wasteful of IP addresses but with VLSM the organisation can deploy a 30
bit extended network prefix, this uses only four IP addresses where one is used on each side
of the link and the remaining two are used for the network and broadcast addresses
respectfully. VLSM solved some of the IPv4 address wastage but at the same time it helped
to contribute to the ballooning in the size of routing tables on network routers (Sportack,
2002). This is one of the reasons why the next addressing system Classless Inter-Domain
Routing (CIDR) was developed.
3.53 IPv4 Classless Inter-domain Routing (CIDR)
Classless Inter-domain Routing (CIDR) looks similar to VLSM, the difference being
that the subnet mask used in VLSM is not routable and only has significance on the local
network. There is also a CIDR notation for writing IP addresses such as the following
194.45.20.10/26 where the /26 indicates that 26 bits are used to identify the network portion
of the IP address, also in CIDR addressing, the network mask is routable which allows for IP
address aggregation and super-netting where super-netting allows multiple smaller networks
to be advertised to the internet as a single larger network (Sportack, 2002). So having
P age | 27

discussed the various addressing techniques, it is important to note that CIDR is now the de
facto standard in routing protocol design.
3.54 Network Address Translation (NAT)

Figure 14 Network Address Translation (NAT)
In 1994 a proposal to deploy Network Address Translation (NAT) was made and as it
was seen by (Egevang & Francis, 1994) The... problems facing the IP Internet are IP address
depletion, and scaling in routing. It is possible that CIDR will not be adequate to maintain the
IP Internet... (however) another short-term solution, address reuse... complements CIDR or
even makes it unnecessary (p. i). An illustration of NAT along with the associated private IP
addresses ranges is shown in figure 14.There are two flavours of NAT the first type known as
Traditional or Basic NAT is described by (Srisuresh & Egevang, 2001) as follows:
A domain with a set of private network addresses could be enabled to communicate
with external networks by dynamically mapping the set of private addresses to a set of
globally valid network addresses. If the number of local nodes are less than or equal to
the number of addresses in the global set, each local address is guaranteed a global
address to map to. Otherwise, nodes allowed to have simultaneous access to external
network are limited by the number of addresses in the global set. Individual local
addresses may be statically mapped to specific global addresses to ensure guaranteed
P age | 28

access to the outside or to allow access to the local host from external hosts via a fixed
public address. (pp. 2-3)
3.55 Network Address Port Translation (NAPT)

Figure 15 Network Address Port Translation (NAPT)
The second flavour of NAT is called Network Address Port Translation (NAPT) and its
key difference from NAT is that tuples of Private Network addresses and TCP/User
Datagram Protocol (UDP) ports are mapped to a single Globally valid tuple of IP address and
TCP/UDP port number as illustrated in figure 15 (Srisuresh & Egevang, 2001). The features
of NAPT are outlined by (Srisuresh & Egevang, 2001) as follows: (1) Inbound access for
services such as DNS need to be statically mapped to a local node. (2) Sessions other than
TCP, UDP and ICMP are not permitted to pass from local nodes to the internet facing side of
the NAPT box. (3) During outbound translation IP packets have their Source Address and
Checksum modified and during inbound translation IP packets have their Destination
Address and Checksum modified. (4) TCP and UDP headers also undergo modification
particularly the TCP/UDP source port on outbound packets and the TCP/UDP destination
port for inbound packets.
P age | 29

In summary this section looked at technologies that have been developed to prolong the
life of IPv4. As IPv6 gains more approval globally the Internet will striate into two realms for
users who are communicating with IPv4 and those who are using IPv6. It is predicted that
these two realms will exist in parallel for decades to come so a bridging mechanism needs to
be built between these two protocols to prevent further striation. These bridging mechanisms
are the subject of the next section.
3.6 Parallel Internets IPv4 & IPv6
To aid the proposed transition from IPv4 to IPv6 end users will undoubtedly use one of
the many transition mechanisms including dual stack tunnelling and translation. This usage
should of course appear transparent to the end user but questions abound at technical
management level as to what transition mechanism to use, where to use it and for how long.
The first mechanism to be examined will be that of the dual IP stack.
3.61 Dual Stack IPv4 & IPv6

Figure 16 Dual stack IPv4 & IPv6 Source: (Amoss & Minoli, 2008)
According to (Amoss & Minoli, 2008) in the dual-stack scheme:
A network node incorporates both IPv4 and IPv6 protocol stacks in parallel where IPv4
applications use the IPv4 stack and IPv6 applications use the IPv6 stack. Flow
P age | 30

decisions in the node are based on the IP header Version field for packets that are
received from the lower layers, a Version field value of 4 results in passing the IP
protocol data unit to the IPv4 layer and a Version field value of 6 results in passing the
IP protocol data unit to the IPv6 layer. When sending packets, the destination address
type received from the upper layers determines the appropriate stack. (p. 109)
(Nordmark & Gilligan, 2005) asserts that in a Dual-stacked configuration IP address
acquisition is more complicated because nodes may be configured with both IPv4 and IPv6
addresses. Dual-stacked nodes use Dynamic Host Configuration Protocol (DHCP) to acquire
their IPv4 addresses, and stateless address auto-configuration and or DHCPv6, to acquire
their IPv6 addresses (p. 4). The dual-stacked node is represented in Figure 16.
3.62 IPv6 Tunnelling
IPv6 tunnelling is carried out to allow connectivity between IPv6 networks that are
separated by IPv4 only network infrastructure, (Beijnum, 2006) outlines this process and
suggests that:
A tunnel is a mechanism whereby one protocol is encapsulated into another protocol to
be transported through a part of the network where the original protocol wouldnt
normally be supported or would have been processed in some undesirable way.
Tunnelling IPv6 in IPv4 is usually done by simply adding an IPv4 header before the
IPv6 packet. The resulting packet is then forwarded to the destination address listed in
the IPv4 header. At this destination, the outer header is stripped away, and the packet is
processed as if it had been received over a regular IPv6-enabled interface. (p. 33)
3.63 Transmission of IPv6 over IPv4 Domains (6over4)
According to (Carpenter & J ung, 1999) 6over4 is a: method to allow isolated IPv6
hosts, located on a physical link which have no directly connected IPv6 router, to become
fully functional IPv6 hosts by using an IPv4 domain that supports IPv4 multicast as their
P age | 31

virtual local link (p. 1). According to many sources including (Beijnum, 2006) 6over4 is
greatly limited in its deploy ability due to its dependence on IPv4 multicast infrastructure
which is not ubiquitous on the internet. Some technical parameters outlined by (Carpenter &
J ung, 1999) provide an insight into 6over4: (1) The default MTU size for IPv6 packets on an
IPv4 domain is 1480 octets; (2) IPv6 packets are transmitted in IPv4 packets with an IPv4
protocol type of 41 (indicating IPv6 encapsulation); (3) The 6over4 interface identifier is
formed by appending zeros to the left of the IPv4 address until the interface ID is 64 bits
long; (4) The IPv6 link-local address is created by appending the interface ID to FE80::/16;
(5) The 6over4 infrastructure must be restricted to the multicast address block
239.192.0.0/16.
3.64 Transmission of IPv6 Domains to IPv4 Clouds (6to4)
6to4 allows IPv6 sites to communicate with other IPv6 sites that are separated by IPv4
infrastructure. (Beijnum, 2006) illustrates the mechanics of 6to4 as follows: (1) every system
that holds a valid, routable IPv4 address can automatically create a 6to4 prefix for itself by
combining its IPv4 address with the 16-bit value 2002 (hexadecimal)... (2) When a 6to4
capable system wants to send a packet to another 6to4 capable system, it encapsulates the
IPv6 packet in an IPv4 packet and addresses this packet to the IPv4 address encoded in the
6to4 destination address. Upon reception, the destination IPv4 host removes the IPv4 header
and continues to process the IPv6 packet. (3) Communication between the 6to4 world and the
regular IPv6 Internet is facilitated by relays... RFC 3068 defines 192.88.99.1 as a 6to4
anycast relay router address... People who run a public 6to4 relay announce to the rest of the
world that theyre prepared to handle traffic toward the IPv4 prefix 192.88.99.0/24 and the
IPv6 prefix 2002::/16. This way, packets automatically find their way to one of the relays
without the need for any relay-specific configuration.

P age | 32

3.65 ISATAP Intra-Site Automatic Tunnel Addressing Protocol
ISATAP is similar to 6to4 but as (Hagen, 2006) communicates The Intra-Site
Automatic Tunnel Addressing Protocol (ISATAP) is designed to provide IPv6 connectivity
for dual-stack nodes over an IPv4-based network (p. 256). An advantage to ISATAP is that
it does not require an IPv4 multicast infrastructure, but it does require that all participating
nodes support ISATAP (Templin, Gleeson, & Thaler, 2008).
3.66 Teredo Tunnelling
Teredo Tunnelling is used to allow communication between IPv6 nodes that are behind
one or more NAT devices. This technique encapsulates IPv6 packets in IPv4 payloads and
then communicates via User Datagram Protocol (UDP) through the NAT device. The
designers of the Teredo service stipulate that it be used as a last resort and canvas that clients
should priorities the use of IPv6 provided natively or via 6to4 (Huitema, 2006).
In summary this section looked at a variety of transition mechanisms that it is hoped
will expedite the adoption of IPv6. Elements of IPv6 are still in research and the same can be
said of the transition mechanisms. Today IPv4 still carries the over whelming majority of
network traffic and if organisations start to move to IPv6 we may see performance issues
arise with the transition mechanisms or they may prove to be very robust, only time will tell.
3.7 Mobile IP
In non mobile networks each attached device is assigned an IP address either statically
or dynamically such that the device is managed in a controlled and predictable fashion. When
it comes to mobile networks, devices roam constantly between different network segments
which require an IP address change at each network boundary.
3.71 Mobile IPv4
To extend the original IP specification to facilitate mobility the mobile IP network is
built around four components as defined by (Helal et al., 2002): (1) Mobile Node (MN) is a
P age | 33

host or a router that changes its point of attachment to the network from one sub network to
another; (2) Home Agent (HA) is a mobile-IP capable router on the mobile nodes home
network. The HA maintains the location information for the mobile node; (3) Foreign Agent
(FA) is a mobile-IP capable router that the mobile node has visited. After attaching to the
foreign network, the mobile node is required to register itself with the FA who then provides
a Care Of Address (COA) to the MN; (4) Corresponding Node (CN) is any other party that
wishes to make contact with the MN. Scholars (Helal, et al., 2002) describe the mechanics of
mobile IPv4 in the following account:
The mobility agents (HA and FA) in the network broadcast their availability through
agent advertisement packets. The mobile node, after connecting to a network, receives
information about the mobility agents through the agent advertisement broadcasts... The
mobile node determines the network it is attached to. If it is connected to the home
network, it operates without mobility services.... If the mobile node is attached to a
foreign network, a care-of-address (extra IP address) is obtained from the FA. The
mobile node operating from a foreign network registers itself with its home agent. The
foreign agent then acts as a relay in this registration process. When the mobile node is
away from its home network, datagrams destined to the mobile node are intercepted by
the home agent, which then tunnels these datagrams to the mobile nodes care-of-
address... In the latter case, the mobile node obtains a temporary IP address on the
foreign agent network to be used for forwarding... The datagrams originating from the
mobile node are routed... (from the foreign agent back to the home agent). (pp. 103-
104)
Call routing in mobile IPv4 is illustrated in figure 17 where data is routed between the
MN and the CN via a tunnel established between the FA and HA.
P age | 34


Figure 17 Mobile IPv4 operation
3.72 Mobile IPv6
Drawing from the many years of experience with mobile IPv4 engineers built mobile
IPv6 with similar features but with a lot of added functionality too. In their mobile IPv4 and
mobile IPv6 comparison table (J ohnson, Perkins, & Arkko, 2004) explain the differences
between these two technologies as follows:
a. There is no need to deploy special routers as "foreign agents", as in mobile IPv4;
mobile IPv6 operates in any location without any special support required from the
local router; support for route optimization is a fundamental part of the protocol,
rather than a nonstandard set of extensions,
b. Mobile IPv6 route optimization can operate securely even without pre-arranged
security associations; it is expected that route optimization can be deployed on a
global scale between all mobile nodes and correspondent nodes,
c. Support is also integrated into mobile IPv6 for allowing route optimization to coexist
efficiently with routers that perform "ingress filtering",
d. The IPv6 Neighbour Un-reach ability Detection assures symmetric reach ability
between the mobile node and its default router in the current location,
P age | 35

e. Most packets sent to a mobile node while away from home in mobile IPv6 are sent
using an IPv6 routing header rather than IP encapsulation, reducing the amount of
resulting overhead compared to mobile IPv4,
f. Mobile IPv6 is decoupled from any particular link layer, as it uses IPv6 Neighbour
Discovery instead of ARP; this also improves the robustness of the protocol,
g. The use of IPv6 encapsulation (and the routing header) removes the need in mobile
IPv6 to manage "tunnel soft state",
h. The dynamic home agent address discovery mechanism in mobile IPv6 returns a
single reply to the mobile node; the directed broadcast approach used in IPv4 returns
separate replies from each home agent.
(pp. 5-6)
(J ohnson, et al., 2004) assert the modus operandi of mobile IPv6 as follows:
A mobile node is always expected to be addressable at its home address, whether it is
currently attached to its home link or is away from home. The "home address" is an IP
address assigned to the mobile node within its home subnet prefix on its home link...
While a mobile node is attached to some foreign link away from home, it is also
addressable at one or more Care Of Addresses (COA). A care-of address is an IP
address associated with a mobile node that has the subnet prefix of a particular foreign
link. The mobile node can acquire its care-of address through conventional IPv6
mechanisms, such as stateless or state full auto-configuration... The association
between a mobile node's home address and care of address is known as a "binding" for
the mobile node. While away from home, a mobile node registers its primary care-of
address with a router on its home link, requesting this router to function as the "home
agent" for the mobile node... Any node communicating with a mobile node is referred
P age | 36

to as a "correspondent node" of the mobile node... There are two possible modes for
communications between the mobile node and a correspondent node. The first mode,
bidirectional tunnelling, does not require mobile IPv6 support from the correspondent
node and is available even if the mobile node has not registered its current binding with
the correspondent node. Packets from the correspondent node are routed to the home
agent and then tunnelled to the mobile node. Packets to the correspondent node are
tunnelled from the mobile node to the home agent ("reverse tunnelled") and then routed
normally from the home network to the correspondent node. In this mode, the home
agent uses proxy Neighbour Discovery to intercept any IPv6 packets addressed to the
mobile node's home address... on the home link. Each intercepted packet is tunnelled to
the mobile node's primary care-of address. This tunnelling is performed using IPv6
encapsulation. The second mode, "route optimization", requires the mobile node to
register its current binding at the correspondent node. Packets from the correspondent
node can be routed directly to the care of address of the mobile node... Routing packets
directly to the mobile nodes care of address allows the shortest communications path to
be used... When routing packets directly to the mobile node, the correspondent node
sets the Destination Address in the IPv6 header to the care of address of the mobile
node... Similarly, the mobile node sets the Source Address in the packet's IPv6 header
to its current care-of address. (pp. 13-14)
Call routing in mobile IPv6 is illustrated in figure 18 where data can take one of two
routes between the MN and the CN, the first being through the bidirectional tunnel from MN
to HA or the second route via the MNs COA on the foreign network direct to the CN, where
the second method is known as route optimisation.
P age | 37


Figure 18 Mobile IPv6 call processing
3.8 Chapter Summary
In summary this chapter looked at mobile IP from the perspective of IPv4 and IPv6.
The issue of IPv4 address depletion effects mobile networks to the same extent as wired
networks; this has lead to the use of NAT devices on mobile networks which effects network
performance; IPv6 may fix some issues but its adoption on mobile networks is quite slow.
The next chapter look at extracting performance parameters from the research literature in a
technique known as a Literature Analysis.











P age | 38

CHAPTER 4 - LITERATURE ANALYSIS
4.0 Introduction
The literature analysis is undertaken to extract valid performance parameters which are
used by the research community to aid in making performance related comparisons between
IPv4 and IPv6. Based on this approach, the following parameters have been established as
valid indicants for performance comparison: Throughput, Round Trip Time (RTT),
Performance & Operating System Dependence, Application Performance and Scalability.
4.1 Throughput
Starting with a throughput evaluation of IPv4 and IPv6 and examining work carried out
at the Central University of Venezuela; in an effort to alleviate IPv4 traffic congestion issues
(Gamess & Morales, 2007) installed an IPv6 network in parallel with their IPv4 network;
they carried out throughput tests from which they could infer that IPv6 has a lower
throughput than the one shown by IPv4. However the difference is not significant (p. 47). In
other work (Shiau, Li, Chao, & Hsu, 2006) carried out a throughput evaluation of IPv6 and
IPv4 on the Taiwan Advanced Research & Education Network (TWAREN) where
experimental results reveal:
In a real large-scale network, we obtained a minor degradation (roughly2% for TCP) on
IPv6 compared to IPv4 networks because the overhead of the IPv6 address size is more
significant (128 bits and 32 bits respectfully). For example, for a message size of 256
bytes, overhead due to the address size is 6.25% and 1.56% for IPv6 and IPv4 networks
respectively, whereas for a message size of 1408 bytes, overhead drops to 1.13% and
0.28% for IPv6 and IPv4 networks respectively... From the UDP throughput results we
observed that there were very close throughputs for both IPv4 and IPv6 networks in
small message sizes or messages with lower Constant Bit Rate (CBR). However, above
P age | 39

the 512 byte message size... we find that... the IPv4 network yields about 13.7% higher
throughput than the IPv6 network. (p. 3116)
(Shiau, et al., 2006) believe: the Nagle algorithm and the delayed acknowledgement
process in the TCP stack are optimised for IPv4 and thus hinder slightly the performance of
IPv6 (p. 3120).
In throughput tests carried out by (Law, Lai, Tan, & Lau, 2008) where they
downloaded a range of small (1MB) to enormous (100MB) file sizes from dual-stack servers;
they concluded from the throughput tests that: IPv6 throughput is higher than IPv4
throughput, especially for large and enormous file download sizes. This can be explained by
the fact that the IPv6 backbone network is less congested compared to the IPv4 backbone
network (p. 5927).
An interesting test using the network simulator (ns-2) to evaluate IPv4/IPv6
deployment over dedicated links (Sanguankotchakorn & Somrobru, 2005) configured an IPv6
network to communicate with an IPv4 network through a Tunnel End Point (TEP) or dual
stacked border router; aggregating VoIP IPv4, Internet traffic IPv4, FTP IPv6 and MEPG-4
IPv6 traffic over a single link they discovered:
IPv6 has better performance than IPv4; especially when the traffic density of IPv6
sessions increases, the bandwidth for IPv6 session increases at the expense of the
decrement of the bandwidth for IPv4 session. On the other hand, as we increase the
traffic density of IPv4 sessions, the bandwidth for IPv4 session does not increase due to
its lower priority, it is apparent that the increment of packet size of IPv6 traffic results
in the increment a little bit of the Mean End-to-End Delay. (p. 248)
Measurements carried out at the Taiwan Advanced Research and Education Network
(TWAREN) by (Wu, Chao, Tsuei, & Li, 2005) revealed that in efficiency tests of the
P age | 40

TWAREN back-bone, IPv4 out preformed IPv6; in tests carried out on their Gigabit Ethernet
network they found that:
The highest throughput for IPv4 UDP packets reached 811Mbps under the no packet
loss condition. The throughput for the IPv6 side was about 715Mbps, which is roughly
88% that of the IPv4 case. The TCP packet test result reached the highest throughput at
859Mbps for IPv4 TCP when the window size was set to 256 Kb. The throughput on
the IPv6 side was about 770Mbps, roughly 89% that of the IPv4 case. (p. 418)
4.2 Round Trip Time (RTT), Jitter & Packet Loss Rate
RTT is the time it takes for a packet to travel from one network node to the next
network node and then return to the original sending node again. J itter according to (Bates,
2002) is: J itter (variable delay) is a variation of the inter-packet delivery time introduced by
the processing of each packet across the network, coupled with transmission delay across the
medium (p. 503). Turning now to the research findings of (Shiau, et al., 2006), with regard
to delay jitter for both IPv4 and IPv6 networks they found that:
jitter was below 16ms and also that the higher the Constant Bit Rate (CBR) and the
packet size, the higher the value of delay jitter; when it came to measuring packet loss
rate it was observed that IPv4 and IPv6 had similar rates of loss but note that the loss
rate drops using a combination of low CBR and large packet size, however above a
CBR of 600Mbps both IPv4 and IPv6 experience a packet loss rate of 90%. In their
final test (Shiau, et al., 2006) measured packet round trip time and they found that:
The round trip time of the IPv6 network is always longer than that of the IPv4 network
in any message size category because of the higher header overheads associated with
IPv6 networks (p. 3120).
Researchers based at the Hong Kong Advanced Research Network (HARNET)
evaluated IPv4 and IPv6 using the metrics of; hop count and round trip time; (Law, et al.,
P age | 41

2008) found that hop count tests revealed IPv6 packets had to travel further than IPv4
packets, due to the fact that there are less IPv6 nodes in the world compared to IPv4 nodes.
This is important to remember when next considering the results of their round trip time
experiment; (Law, et al., 2008) found that:
The IPv6 RTTs are higher than the IPv4 RTTs. The average values of the IPv6 RTT
and IPv4 RTT are 403.36ms and 272.78ms respectively... However, due to the fact that
the number of IPv6 nodes and its concentration are lower and less dense compared to
IPv4 nodes, and that the direct link connectivity of the IPv6 networks is lower
compared to IPv4 networks... translates to higher IPv6 RTTs compared to IPv4 RTTs.
(p. 5926)
In a non simulated experiment carried out from the China Education and Research
Network (CERNET) (Wang, Ye, & Li, 2005) collected packet data from 936 IPv4/IPv6 dual-
stacked web servers in 44 countries; they measured packet loss, round trip time (RTT) and
the performance of IPv6-in-IPv4 tunnels. Keeping in mind for (Wang, et al., 2005) that Due
to the development and enormous diversity of the Internet, average packet loss rate in
different studies is reported in a wide range (p. 73). It is interesting to note that this
experiment took measurements across three regions of the internet controlled by Rseaux IP
Europens (RIPE), American Registry for Internet Numbers (ARIN) and Asia Pacific
Network Information Centre (APNIC). For packet loss (Wang, et al., 2005) found that:
The IPv6 and the IPv4 connections have an average packet loss rate of 3.09% and
0.76% respectively. Round-trip time (RTT) is an important parameter to indicate the
quality-of-service of networks. The RIPE nodes cluster into two narrow bands with
IPv6 RTT range approximately from 320ms to 420ms and from 450ms to 550ms (IPv4)
respectively... The ARIN nodes do not have such a notable clustering characteristic as
the RIPE (nodes)... Most of the ARIN nodes are around the unity line (IPv6 RTT=IPv4
P age | 42

RTT). In spite of their small total number, the APNIC nodes have large variance of
RTT values due to their topology diversity also note that, although about 66.7% of the
dual-stack nodes have smaller IPv6 RTTs than IPv4 RTTs, 58.0% of the nodes suffer
larger IPv6 RTT fluctuation (in terms of RTT standard deviation) at the same time. It is
recently believed that tunnels degrade the network performance and reliability. It is
obvious that tunnelling does not seem to introduce notable extra delays. Most tunnelled
IPv6 paths have smaller RTT values than their IPv4 counterparts, and the reductions are
often more than 100ms. (pp. 74-76)
In an effort to identify IPv6 network problems in the dual-stacked world (Cho, Luckie,
& Huffaker, 2004) took measurements from three Regional Internet Registries (RIR)s on the
internet APNIC, RIPE and ARIN; ping tests were carried out on 4,086 dual-stacked
IPv4/IPv6 nodes across these three RIRs, tests revealed that of the 4,086 dual-stacked nodes:
about 16% are reachable by IPv4 but not by IPv6 even though they have AAAA records (an
IPv6 DNS entry) and these sites would then force communicating peers to timeout with IPv6
before falling back to IPv4 (p. 285). Of the dual-stacked nodes that did respond to ping tests
(Cho, et al., 2004) found: the majority of the nodes have similar RTT for both IPv4 and
IPv6, a number of individual nodes have IPv6 performance issues specific to the node or the
site (p. 286). When correlating the ratio of IPv6 only to IPv4 only nodes for each RIR, (Cho,
et al., 2004) also found that: ARIN was about 0.23. The low level of IPv6 responding in
ARIN could be the result of the low level of commitment to IPv6 in the US (p. 286). Given
that the metrics of RTT, J itter and Packet Loss Rate are very particular to each individual
network and therefore cannot be generalised to other cases, these metrics do reveal that the
density of the IPv6 network is a lot lower than the IPv4 network which will have advantages
and disadvantages for the Internet community.
4.3 Performance & Operating System (OS) Dependence
P age | 43

In tests carried out by (Gamess & Morales, 2007) at the Central University of
Venezuela, OS dependency tests on each of the following Windows XP-SP2, Solaris 10 and
Debian 3.1 found that: Windows XP and Debian has similar TCP and UDP throughputs.
Both (Windows XP and Debian) outperform the throughput of Solaris for small TCP and
UDP payload. However, Solaris shows an equal or superior performance for large data (p.
47). In similar work to evaluate IPv4/IPv6 OS dependence on the following operating
systems; Windows XP, FreeBSD 6.1 and Fedora Core 5, (Law, et al., 2008) found: results
show that FreeBSD and Fedora clients obtained similar throughput as each other, the
Windows client performed the worst, the Windows client can only obtain at most 50% of the
average download rate of the FreeBSD and Fedora clients (p. 5927).
With a narrower focus on Windows operating systems (Narayan & Yhi, 2009)
examined DNS and game (Counter Strike and Quake 3 Arena) traffic performance on
Windows 7, Windows Vista, Windows XP, Windows 2003 and Windows 2008 where their
results reveal that:
Windows Vista gives the lowest through put for DNS traffic. For IPv6, the newer
operating systems give a higher throughput value. Windows 7 has the highest round trip
time and Windows XP the lowest for DNS traffic. Windows 7 throughput values for
Counter Strike and Quake 3 game traffic is comparatively higher than that of the other
operating systems. Latency values between the operating systems are comparable,
except for Windows Server 2003 these values are much higher than the rest. (p. 4)
In similar work to examine the effect of the operating system on IPv4 and IPv6
(Narayan, Shang, & Fan, 2009) measured throughput, delay, jitter and CPU usage on
the following operating systems Windows XP, Windows Vista, Windows Server 2003 &
Windows Server 2008 and also Linux Fedora and Linux Ubuntu again their results show that:
P age | 44

For packet sizes larger than 256 bytes, IPv4 always gives a slightly better throughput
than IPv6 (consistent with theory). Windows Vista throughput values for most packets
sizes for both TCP and UDP traffic are lower than Linux Ubuntu by up to 5%.... For
TCP traffic, Windows Vista (average) delay is approximately zero but Linux Ubuntu
averages around 500ms, and for UDP Windows Vista delay is approximately 4 times
lower than Ubuntu. J itter values for Windows Vista are lower than that of Linux
Ubuntu for TCP traffic. For almost all packet sizes, Windows Vista uses more CPU
resources on both the sending and the receiving nodes. TCP and UDP traffic decoding
uses more CPU resources in Windows Vista than Linux Ubuntu. (p. 4)
In research to test the IP stack of two Windows operating systems with the same kernel
researchers pitted Windows XP against Windows Server 2003 (Narayan, Kolahi, Sunarto,
Nguyen, & Mani, 2008) tested IPv4 and IPv6 throughput of both systems and found that:
Using TCP and UDP traffic between two nodes for small packet sizes Windows XP and
Server 2003 have a throughput difference of approximately 5%... For large packet size
TCP traffic on Windows Server 2003 shows a difference of 10.4% and UDP traffic on
Windows XP shows 12%. (p. 668)
In a comparison of end systems in particular Windows 2000, Redhat Linux 7.3 and
Solaris 8.0 (Zeadally, Wasseem, & Raicu, 2004) measured throughput, round trip time,
socket creation time, TCP connection time and web client/server simulation; they conclude
that:
IPv6 (as well as IPv4) on Linux outperforms Windows 2000 and Solaris 8 IPv6 (and
IPv4) implementations for all the metrics used... we obtained a minor degradation in
throughput and round-trip latency performances for IPv6 compared to IPv4 on
Windows 2000 and Solaris. However, we obtained improved (i.e. lower) round-trip
latencies for IPv6 compared to IPv4 for Linux... TCP/IPv4 and TCP/IPv6 socket
P age | 45

creation times were sixteen times and nineteen times lower, respectively, on Linux
compared to those on Windows 2000, and about four times lower (for IPv4 and IPv6)
compared to Solaris. The web simulation results revealed a four-fold increase in
performance (i.e. number of connections per second) for IPv6 on Solaris and Linux
against IPv6 on Windows 2000.
The fact that we obtained a degradation of 5%, 6% and 22% for Linux, Solaris and
Windows 2000, respectively, demonstrates that IPv6-based web servers running Solaris or
Linux will yield higher performance than those running Windows 2000. (p. 242)
In a comparison of packet transmission on a pure IPv6 network (Mohamed, Buhari, &
Saleem, 2006) used the metrics of round trip time, throughput, socket creation time, TCP
connection time and number of (client/server) connection per second, attainable on Windows
2003, FreeBSD 4.9 and Redhat Linux 9.0 where experimental results reveal:
Redhat Linux 9.0 implementation of the IPv6 protocol stack has overall good
performance under loop-back (transmitter to receiver via attenuator) test-bed. The
performance of IPv6 with FreeBSD 4.9 deserves the next higher overall performance.
Windows 2003 has comparatively poor performance under loop-back test-bed with
direct-link test-bed II (placing a hub between the two IPv6 workstations); all the three
operating systems have closer performance. However, Windows 2003 seems to have
better performance with direct-link test-bed With test-bed III (placing a router between
the two IPv6 workstations), the performance behaviour is found almost similar to test-
bed II but a decrease in throughput and an increase in Round Trip Time (RTT) is
observed owing to the overhead of router in all the test cases, the UDP of Windows
2003 is found poor. (pp. 432-433)


P age | 46

4.4 Application Performance (FTP, HTTP, VOIP, IPSec)
In this chapter we examine application layer protocols and issues affected by IPv4 and
IPv6 environments. In an interesting test using the network simulator (ns-2) to evaluate
IPv4/IPv6 deployment over dedicated links (Sanguankotchakorn & Somrobru, 2005)
configured an IPv6 network to communicate with an IPv4 network through a Tunnel End
Point (TEP) or dual stacked border router; aggregating VoIP IPv4, Internet traffic IPv4, FTP
IPv6 and MEPG-4 IPv6 traffic over a single link they found that:
IPv6 has better performance than IPv4. Especially when the traffic density of IPv6
sessions increases, the bandwidth for IPv6 session increases at the expense of the
decrement of the bandwidth for IPv4 session. On the other hand, as we increase the
traffic density of IPv4 session, the bandwidth for IPv4 session does not increase due to
its lower priority, it is apparent that the increment of packet size of IPv6 traffic results
in the increment a little bit of the Mean End-to-End Delay.(p. 248)
Due to the mandatory requirements for IPv6 to use Internet Protocol Security (IPSec)
(Mujinga, Muyingi, & Rao, 2006) carried out an experiment to find the IPSec overhead in a
dual-stacked IPv4/IPv6 test bed network; they gauged IPv4/IPv6 performance using the
metrics of percentage overhead, average RTT and download times of Hyper Text Transfer
Protocol (HTTP), File Transfer Protocol (FTP) and Trivial File Transfer Protocol (TFTP).
From their experiments (Mujinga, et al., 2006) observed the:
The impact of IPSec overhead on all protocols we tested is higher for smaller packets as
compared to larger packets for both IPv4 and IPv6; we also noticed that, the use of both
IPSec (Authentication Header (AH) and Encapsulating Security Payload (ESP))
protocols increases the overhead cumulatively as the overhead of each protocol. The
tests also showed that, in some cases there is security advantage in using both IPSec
P age | 47

protocols (AH and ESP) compared to none or one protocol, due to very minimal
performance costs. (p. 697)
In an evaluation of IPv4/IPv6s ability to stream audio and video over a network
(Ismail & Abidin, 2009) used MRTG traffic graphs to gauge network performance over a
seven day time period, for daily (5 minute average) tests: Both Internet Protocol (IP)
versions have approximately the same throughput during streaming activities (p. 447), but
for weekly (30 minute average) tests reveal: IPv6 produce low throughput at server and
client workstation compare to IPv4 during streaming activities (Ismail & Abidin, 2009, p.
447). In their final note these researchers found that Queue delay increases with the network
load and IPv6 suffers higher delay, which can have a knock on effect on IPv6 throughput.
4.5 Scalability

Figure 19 Growth of the IPv4 BGP table Source: (Sailan, Hassan, & Patel, 2009)
When it comes to scalability IPv4 and IPv6 really stand apart. As defined in (Deering &
Hinden, 1998; Postel, 1981b) IPv4 is built on a 32 bit address scheme and IPv6 is built on a
128 bit addressing scheme. To prolong IPv4, wide spread adoption of NAT occurred which in
P age | 48

turn helped to erode the end to end connectivity architecture of the Internet again striating the
network creating more complex and bloated IPv4 routing tables, this is illustrated in figure 19
which shows a graph of advertised Border Gateway Protocol (BGP) routes. Routing
information has to be stored on gateway routers in a file called a Routing Information Base
(RIB) and the bigger this file the more processing power is required on the part of the
gateway router which in turn increases the purchasing and running costs of the router.
4.6 Comparative Summary of Literature Review and Literature Analysis
In this section the literature review and literature analysis are summarised and the
results are presented in tabular form. This will highlight the positive aspects of each of the
IPv4 and IPv6 protocols.
CATEGORY: IPV4 IPV6
IP address size (bits): 32 128
IP addresses achievable:

IP address format: 255.255.255.255 FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF
Minimum datagram size (bytes): 576 1500
Maximum datagram size (bytes): 65,535 4,294,967,295 (using J umbo-grams)
IP header size (bytes): 20 40
MTU on Ethernet (bytes): 1500 1500
Fragmentation support: Yes Yes, (only at source node)
IP address discovery: Via ARP Via NDP
Multicast support: Yes, via IGMP Yes, via MLD
CIDR support: Yes Yes
Mobile IP support: Yes Yes
Throughput performance: IPv4 =IPv6
J itter and packet loss rate: IPv4 =IPv6
Round trip time: (ms) IPv6 >IPv4
P age | 49

OS dependence: IPv4 & IPv6 work just as well on newer OSs
Top Ranking OS: Linux (1st), Solaris (2nd), Windows (3rd)
Application layer performance: IPv6 out performs IPv4 in dense traffic situations

4.7 Chapter Summary
This chapter examined research carried out around the world that looked to measure
performance between IPv4 and IPv6. All of the criteria are of a technical nature and do not
provide a broader context such as cost of implementation and maintenance.
The next chapter provides some real world information on two organisations NUIG-
(ISS) and HEAnet Ltd in the Case Study.



















P age | 50

CHAPTER 5 - CASE STUDY
5.0 Introduction
As part of my thesis development in 2009 I spent six months working at HEAnet Ltd in
Dublin. As a service to their clients HEAnet provide both IPv4 and IPv6 connectivity. During
placement I learned that my home university, NUI Galway have little or no interest in
deploying IPv6. It became clear that an interesting comparison could be drawn between these
two governmentally and technologically linked organisations HEAnet and NUIG; where on
the one hand we have HEAnet who have completed deployment of IPv6 and on the other we
have NUIG who have little or no interest in IPv6 deployment. A detailed account of services
and operations provided by HEAnet and NUIG-ISS is given in the following sections.
5.1 HEAnet
HEAnet are the National Research & Education Network (NREN) of Ireland. They
provide Internet connectivity for the primary, secondary and tertiary educational institutions
of Ireland. HEAnet have deployed IPv6 on their network using the dual stack transition
mechanism. They encourage their customers to adopt IPv6 on their own constituent networks
but realise that IPv4 will be around for the foreseeable future and as such HEAnet must
continue to provide IPv4 services.
In Ireland all school and university internet connections are aggregated together and
connected to the global internet at data-centres in Dublin via the National 10Gbits/s Fibre-
Optic network. HEAnet striate the NREN in a tiered manner similar to that seen in the OSI
model. Layer 1 and 2 are carried over the National Fibre-Optic network that runs the length
and breadth of the country, effectively creating one big Ethernet. Layer 1 and 2 connectivity
is established using the ADVA Optical Networking FSP 3000. This Fibre Services Platform
(FSP) uses Wavelength Division Multiplexing (WDM) to multiplex and transport up to 80
wavelengths per fibre pair, yielding up to 40Gbits/s throughput. In figure 20 (ADVA, 2010)
P age | 51

illustrate the channel spacing associated with two flavours of WDM, Course and Dense Wave
Division Multiplexing where DWDM has become the de facto standard
(www.advaoptical.com).

Figure 20 WDM in the range 230.6 to 187.5GHz Source: (ADVA, 2010)
At each college or university the FSP 3000 is connected to an Edge or Aggregation
router, in the majority of cases this device is a Cisco 7600. With particular reference to NUI
Galway the Cisco 7600 is fed by a 10Gbit/s link to a Cisco 3750 optical switch, this in turn
provides 1Gbit/s fibre-optic connectivity to each campus building. This provides layer 3 and
above services to the computer suites and VOIP telephony equipment. A map of the HEAnet
National 10Gbit/s Fibre Network is illustrated in figure 21.

H
services
associat



HEAnet not
s to their cli
ted descript
Figure 2
only provid
ient base, as
tion are sho
21 HEAnet N
de National
s illustrated
wn in table
National 10
network co
d in (HEAne
22.
0Gb/s Fibre
onnectivity t
et, 2009) the
Network
they also pr
ese services
P a
ovide a rang
s and their
ge | 52

ge of
P age | 53

SERVICE:DESCRIPTION
IPCONNECTIVITY: Enables Internet transit at speeds up to 10Gbit/s within Ireland and over
connections to the UK and Europe.
POINTTOPOINTSERVICES: Enables point-to-point services to serve intra-institute and
inter-institute needs.
RESILIENTCONNECTIVITY: Enables clients to build resilient connectivity solutions,
guaranteeing the highest levels of service availability.
COLOCATION: Enables clients to install equipment in a managed data centre facility.
WEBSITEHOSTING: Enables website hosting services to interest groups belonging to the
Irish higher education and research community
WEBSITEHOTSTANDBY: Enables clients, fail over protection for their primary web servers.
WIKIHOSTING: Enables in addition to regular website hosting, the HEAnet web hosting
platform supports Media Wiki, which supports websites which require collaborative
development of website content.
VIRTUALLEARNINGENVIRONMENTHOSTING: Enables the management of educational
courses, especially by helping teachers and learners with course administration.
SOFTWAREMIRRORING: Enables a mirror service to mirror free software and content
relevant to the academia.
IPADDRESSES: HEAnet provides IP addresses to its clients in education and research in
Ireland.
LOOKINGGLASS: We host a Looking-Glass which provides a view of the Internet as seen
from our routers.
MULTICASTIP: Multicast is fully deployed across the HEAnet backbone. Multicast enables
P age | 54

efficient delivery of IPTV services across your campus network.
NETFLOW: Netflows network management applications allow network traffic accounting,
usage-based network monitoring, network planning and Denial of Services monitoring of
client data flows.
NTP: An accurate time service is provided to clients through HEAnet NTP servers.
.IEREGISTRATION: HEAnet member institutions may register 2
nd
level domain names under
the .ie domain.
DNS: HEAnet provides a DNS service for HEAnet customers based on high availability
primary and secondary name-servers.
MAILINGLISTS: Any HEAnet member institution may avail of this service to run electronic
discussion lists of relevance to the Irish education and research community.
USENETNEWS: Enables a full USENET news service to clients in both IPv6 and IPv4.
ANTISPAM: Enables automatic detection of email spam and reporting of spamming sites.
SECURITYSCANNING: This Security Scanning service is a vulnerability and risk assessment
service that allows HEAnet clients to scan their own IP networks for security threats.
CERT: This service operates to provide a single, trusted point of contact for HEAnet clients to
deal with computer security incidents and their prevention.
SERVERCERTIFICATESERVICE(SCS): This service allows server certificates to be used for
institution services which require encryption, including web, email and SSL based services
that require trusted certificates.
MULTIMEDIAVIDEOCONFERENCING: This service is available to all HEAnet clients.
VIDEOSTREAMING: This service allows clients to broadcast video content to very large
numbers of participants over IP networks.
P age | 55

VIDEOCONTENTARCHIVING: Enables clients to upload their own content, where it can be
made generally available over the network without impacting the clients own bandwidth.
EDUROAM: Eduroam, which stands for Education Roaming, allows for inter-institutional
roaming. Being part of eduroam allows a user visiting another eduroam-enabled institution to
log on to that WLAN using the same username and password as they would use at their home
institution.
Table 22 HEAnet Service Catalogue (2009) Source : (HEAnet, 2009)
5.2 NUIG-ISS
The National University of Ireland is situated on the banks of the river Corrib right in
the heart of Galway city. According to (NUIGalway, 2010) the university first opened its
doors in 1849 when it was known as Queens College; in 1908 it became known as
University College Galway and finally in 1997 it was renamed to National University of
Ireland Galway. With 16,000 students and more than 2,200 staff, NUI Galway has a
distinguished reputation for teaching and research excellence. Providing IT solutions for
students and staff is the task charged to the ISS Information Solutions and Services
department. The ISS department operates a campus wide network that includes a
Metropolitan Area Network (MAN) that interconnects off-campus buildings. NUIG ISS
operate an IPv4 only network and they do not have any plans to upgrade their infrastructure
to IPv6 for the foreseeable future. The ISS provides a range of services for students and staff
as table 23 illustrates.




P age | 56

SERVICE:DESCRIPTION
DATACENTRESERVICES: Server Hosting, Virtual Server Service, Data Hosting and Backup.
EMAIL: Student Mail, Staff Mail, BlackBerry and Mobile Data.
ICTSTRATEGYCOORDINATION: Code of practice for Mass emails, Support for software
costs, Web Policy.
NETWORK: Wired, Wireless, Network Security including anti-virus and malware, Remote
Access to Network Resources, Wide Area Network (WAN).
SERVICEDESK: Service Desk Ticketing System - logging, reporting and monitoring, Service
Desk (Advisory and 1st level troubleshooting), Training, User accounts
(Provisioning/Access), Node registration (Provisioning/Access), Conference Liaison.
SOFTWARE: Software Distribution, Software Procurement.
STAFFDESKTOPSUPPORT(2NDLEVELDESKTOPSUPPORT): Support services provided
include - Network connection and moves, Software configuration and troubleshooting,
Hardware support for computers and printers, Advice on the procurement of desktop and
laptop computers in NUI Galway.
STUDENTDESKTOP: PC Suites (Provisioning/Readiness), Assistive Technology, Student
Printing.
TEACHING&LEARNINGSUPPORT: Blackboard, LEAS - Linux Environment for Academic
Studies, Exam services, PC Suite booking, Lecture Theatre PCs.
WEBSERVICES: Web support services including CMS (Content Management System), Staff
Intranet, University Web site and domain hosting.
Table 23 NUIG ISS Service Catalogue Source: (NUIGISS, 2010)


P age | 57

5.3 Chapter Summary
This chapter gave a broad account of when and where the choices were made to peruse
a thesis on the topic of IPv4 and IPv6. This chapter also gave a sense of how wide reaching
IPv4 and IPv6 issues are if one looks at the service catalogues from both HEAnet and NUIG-
(ISS), each one of these services can be effected in both a positive and negative manner. The
following chapter, questionnaire and interview design details the structure and rationale
behind the questionnaire and interview that was carried out with the cooperation of Gareth
Eason of HEAnet and Tom Regan of NUIG-(ISS).

















P age | 58

CHAPTER 6 - QUESTIONNAIRE AND INTERVIEW DESIGN
6.0 Introduction
The design of the questionnaire drew on a number of tools borrowed from the domain
of corporate strategy and business management. These tools and their associated descriptions
are outlined as follows.
6.1 PESTEL
The first tool is known as: Political, Economic, Social, Technological, Environmental
and Legal (PESTEL). This tool is used to extract information from influences that exist in the
Macro-Environment in which organisations such as HEAnet and NUI Galway operate.
Scholars (J ohnsn, Scholes, & Whittington, 2008) define PESTEL as follows:
The PESTEL framework, which categorises environmental influences into six main
types: political, economic, social, technological, environmental and legal... (Where)
Politics highlights the role of governments; Economics refers to macro-economic
factors such as exchange rates, business cycles and differential economic growth rates
around the world; Social influences include changing cultures and demographics, for
example ageing populations in western societies; Technological influences refer to
innovations such as the Internet, nanotechnology or the rise of new composite
materials; Environmental stands specifically for green issues, such as pollution and
waste; and finally Legal embraces legislative constraints or change, such as health and
safety legislation or restrictions on company mergers and acquisitions. (p. 55)
6.2 SWOT
The Strengths Weaknesses Opportunities & Threats (SWOT) diagnostic tool is used as
(J ohnsn, et al., 2008) put it: SWOT summarises the key issues from the business
environment and the strategic capabilities of an organisation that are most likely to impact on
strategy development. This can be useful as a basis against which to judge future strategic
P age | 59

choices... (Its) aim is to identify the extent to which the current strengths and weaknesses are
relevant to, and capable of, dealing with the threats or capitalising on the opportunities in the
business environment. (p. 119)
6.3 BCP
Business Continuity Planning (BCP) at its core is a disaster recovery plan for business
organisations. A few key points about BCP are outlined by (Barnes, 2001) as follows
a. (A BCP is defined as) An integrated set of procedures and resource information that
is used to recover from a disaster that has caused a disruption to business operations.
b. A disaster is defined as a disruption of business operations that stops the
organization from providing its critical services caused by the absence of critical
resources, (including) People and skill sets, Facilities, Communications, Power,
Information access.
c. A disaster will impact on the financial health of an organization. Extra expenses and
loss of cash flow cause an erosion of an organizations equity position. Time is the
enemy. (What does BCP do?) Upon the declaration of a disaster, it activates
preapproved policies and Authorities... (And) it restores the outflow of services with
the least possible cost to the organization.
(pp. 39-40)
6.4 Questionnaire Structure
The questionnaire is broken down into the following five sections: General, Cost,
Strategy, Innovation and finally Technical. The General section was used to gauge the current
status of HEAnets and NUIGs IPv4 resources. The Cost section helped to see if both
organisations HEAnet and NUIG-ISS have aligned their IPv4/IPv6 technology spend with
their IT upgrade cycle or have they incurred IPv4/IPv6 costs in a more disorganised fashion.
The Strategy section was helpful in (1) gauging the degree of alignment between HEAnets
P age | 60

and NUIG-ISSs business and IT strategy and (2) what kind of internal resources and threats
exist for each organisation through the use of a SWOT analysis. The strategy section also
helped extract perceived external threats to both organisations using the PESTEL tool. The
Innovation section was used to see if both organisations are cognisant of future, potential
technology changes and realise that their actions today could have far reaching consequences
in the future. The final Technical section comprised among others, of questions from the
literature analysis so that a relationship could be established between the real world data
extracted from the questionnaire and the results gleaned from academic research papers.
6.5 Interview Structure
For the pre-structured interview my thesis supervisor selected a suitable candidate
(Tom Regan) from the NUIG-ISS department and I opted to choose (Gareth Eason) who was
my supervisor during my six month placement at HEAnet Ltd. I had permission to make an
audio recording of my interview with Gareth Eason; this helped with generating a trans-script
of the interview. Tom Regan had written down most of the answers to the questions on the
questionnaire, I still asked him all the questions just to qualify the answers and ensure we
were both singing from the same hymn sheet. In interviewing Gareth Eason I had to travel to
Dublin to the HEAnet offices in the International Financial Services Centre (IFSC) where the
interview was carried out in a meeting room for two hours approximately; with regard to
Tom Regan no travel was required as we both work on the same NUIG campus, Toms
interview lasted for one hour. Both Gareth Eason and Tom Regan are extremely technically
competent and are very well respected in their domains of expertise.
6.6 Chapter Summary
This chapter looked at the design and structure of the questionnaire and interview
technique used to extract real world data from the case study examples. This data along with
P age | 61

the data that comprises this thesis will be analysed in the following chapter, Results and
Analysis.























P age | 62

CHAPTER 7 - RESULTS AND ANALYSIS
7.0 Introduction
The research data accumulated in this thesis was derived from four sources namely: (1)
Literature review, (2) Literature analysis, (3) Questionnaire and (4) Case study. Based on
these sources of evidence, the following are the main findings...
7.1 Literature Review Analysis
Looking firstly at the literature review it is evident that IPv6 has a superior IP
addressing scheme in comparison to IPv4. IP address auto-configuration also is a major plus
in favour of IPv6. There is a difference in IP packet header size from IPv4 to IPv6 but IPv6
has the advantage through its use of optional header extensions giving the protocol great
flexibility. Payload capabilities of IPv6 surpass in orders of magnitude those of IPv4.
Fragmentation should be less of an issue for IPv6 compared to IPv4. IP Multicasting has also
been refined for the better in IPv6.
7.2 Literature Analysis (Analysis)
From the second source the literature analysis revealed that IPv4 and IPv6 on average
currently have similar throughput rates. J itter and Packet Loss Rate are similar for IPv4 and
IPv6 but IPv6 experiences considerable more Round Trip Time (RTT). In Operating System
(OS) dependency tests it appears that IPv4 and IPv6 work well on newer operating systems
and they also work better on Linux and Solaris systems as opposed to Windows systems. In
application layer performance tests IPv6 out performs IPv4 in dense traffic situations but has
a similar performance profile for VOIP streaming and packet encryption.
7.3 Questionnaire Analysis
From the third source, the questionnaire, this provided real-world data encapsulated in a
rich contextual environment. On the one hand we have HEAnet who have fully deployed
IPv6 on their network and plan on becoming an IPv6 only network by 2015. The technical
P age | 63

personnel at HEAnet are well versed in IPv6 and as such any technical difficulties
encountered were quickly overcome. Their Schools Network though is still IPv4 and will
remain so for the foreseeable future. They see education, training and cost as an issue for
themselves and their customers; the roots of these issues lie in graduates (potential staff) not
having knowledge of IPv6 and vendors engaging in product differentiation to recover R&D
costs. Interestingly HEAnet do not use firewalls to guard their network instead they use
workstation level intrusion detection, this has massive cost savings due to more workstations
having IPv6 ready firewalls as opposed to enterprise class firewall solutions having quasi
support for IPv6.
On the polar opposite to HEAnet is NUIG-(ISS) this organisation will not be effected
by the shortage in IPv4 addresses due to the massive quantity of addresses with which they
already have. IPv6 does not and will not feature on their IT strategy for the foreseeable
future. They do however follow industry trends and have regular IT upgrade cycles; this has
the effect of slowly introducing IPv6 capable equipment. A major hurdle for them would be
to retrain their staff on how to use IPv6 in service delivery, if they were to adopt it; also
selling the benefits of IPv6 to top level management will be difficult particularly in the
current recessionary climate. They did identify that in their use of NAT it has a limited
address space and that NAT breaks many applications so care must be taken before
acquisition of new software. The network maintained by NUIG-(ISS) is very stable and
works, so they really have gotten IPv4 to work hard for their organisation. With regard to
Innovation and its potential relationship with IPv6 an interesting point was raised that if
NUIG-(ISS) or Irish companies for that matter do not adopt IPv6 for innovative development
they may not be able to win IPv6 related US Government contracts!


P age | 64

7.4 Case Study Analysis
Looking at both organisations HEAnet and NUIG-(ISS) one can see that they are in a
similar line of business, that being, both deliver Internet connectivity and technical support to
their respective end-users. Although both organisations provide network connectivity NUIG-
(ISS) have to support a vastly larger number of end-user applications compared to HEAnet.
However once applications communicate over the Internet NUIG-(ISS) become very
dependent on HEAnet, in this sense HEAnet are a critical enabler for NUIG-(ISS) networked
services.
7.5 Summary of Questionnaire Results
With a view to broadening the appeal of the findings from questionnaire here is a
comparative summary of results taken from Gareth Eason of HEAnet and Tom Regan of
NUIG-(ISS). For the majority of this summary the questions and answers are very much
simplified for the interests of brevity.
QUESTION GARETHEASON
OFHEANET
TOMREGAN
OFNUIG(ISS)
AreyourIPv4addressresources
scarce?
No No
DoyouuseNAT? No Yes
Doyouplantoacquirefurther
IPv4addressresources?
YesandNo No
Isanyportionofyournetwork
IPv6ready?
Yes No
Whatistheperiodof
HEAnet/NUIG(ISS)ITupgrade
cycle?
5years 4years
Doyouhaveaformalbudgetfor
IPv6deployment?
No No
HaveyouincorporatedIPv6
deploymentinyourITupgrade
cycle?
Yes No
Whathavebeenthefinancial
hurdlesinIPv6deployment?
VendorProductDifferentiation Notapplicable
Whatwillbethefinancialhurdles
toIPv6deployment?
Notapplicable Stafftraining

P age | 65

InthecontextofCOST,what
wouldyouliketoseehappen?
Vendorsshouldstopproduct
differentiation
IPv6knowledgedisseminationand
training
ShouldtheGovernmentprovide
financialassistanceforIPv4/IPv6
issuesandbenefits?
No Yes
WhatisyourITstrategyinthe
contextofIPv4andIPv6?
Dualstackednetwork IPv4only
WhatroledoesIPv6playinthe
alignmentofyourITand
businessstrategy?
Currentdualstackednetworkand
gearisdualstacked
Notapplicable
DoyouseeIPv6playingarolein
yourBCP?
Yes No
IsIPv4addressdepletionathreat
tothealignmentbetweenyourIT
andbusinessstrategy?
No,problemisdealtwith No,plentyofIPv4resources
InthecontextofaPESTEL
analysislistfactorsyoudeem
importantwhenassessingIPv4
andIPv6?
P:USGovernmentsupport
E:Nointerestfromcustomeror
manufacturer
S:Makemorecontentavailableon
IPv6
T:PartsofIPv6arestillintesting
E:100%IPv6maybemoreGreen
thandualstack
L:Manysecurityproductsdont
supportIPv6
P:USGovernmentsupport
E:Costofstafftraining
S:Ubiquitouscomputing
T:IPv6techadvantageswillbea
hardselltomanagement
E:IfIPv6isGreencouldbea
sellingpoint
L:nocomment
InthecontextofaSWOTanalysis
ofIPv4,canyoulistfactorsunder
eachheadingthatIPv4bringsto
yourbusiness?
S:Secure, Supported
W:Lackofaddresses
O:EasyhireIPv4experts
T:AddressDepletion
S:MorefamiliaritywithIPv4
W:NATusesmorepower,breaks
functionality
O:NATusefulforsecuritylogging
T:WeaksecurityinIPv4
InthecontextofaSWOTanalysis
ofIPv6,canyoulistfactorsunder
eachheadingthatIPv6bringsto
yourbusiness?
S:AddressScalability
W:Limitedsupport
O:MoreVendor&content
providersupport
T:IPv6looksverydifferentfrom
IPv4
S:MoreIPaddresses
W:StaffunfamiliarwithIPv6
O:Mobility,moredevices,new
research
T:Lowintegrationwithother
universities
GiventheIrishgovernments
commitmenttoinnovationand
creativityineducationand
research.DoyouseeIPv4and
IPv6beingabletoprovidethe
environmentwithinwhich
innovationsystemscanbeborn?
WemustprovideIPv4andIPv6
connectivityforuniversities.
IfwecanidentifyaspectsofIPv6
thataresuitedtoinnovationwe
mayhaveasellingpoint,weneed
IPv6togetUSGovernment
contracts
DoesyourIPv4networkuse
QoS?
No Yes


P age | 66

AccordingtothelatestIPv6
specification(RFC2460,1998)
QoSinIPv6isstillverymuch
experimental.Howdoyoureact
tothis?
Currentlynotanissue AskCISCO
GiventhatIPv6requiresatleast
1280bytes(butrecommended
1500bytes)Maximum
TransmissionUnit(MTU)sizeon
everylink;canyououtlinesome
prosandconsassociatedwith
this?
Onlyeffectsmanagedlinkswith
EircomorBT.
No,100%Ethernet
Fromasecurityperspectivehow
doyousafeguardyourIPv4and
IPv6network?
Netflow+FSWM DHCPSnooping,Firewalls&Proxy
ResearchhasshownthatIPv6
impactstoagreaterextentthe
CentralProcessingUnit(CPU)
performanceofenduser
workstationswhencomparedto
IPv4.Howdoyourespondto
this?
Modernhardwarewillnegatethis Hardwareupgradewillnegatethis
Haveyoutalkedwithyour
software/hardwarevendorsto
seeiftheyofferIPv6compatible
products?
Yes,newgearmustsupportIPv6 No
WheredoyouseeIPv4andIPv6
inthetechnicalfutureof
HEAnet/NUIG(ISS)?
MoreIPv6andlessIPv4 NochangefromIPv4inthemedium
term
InyourexperiencewithIPv6
whatdoyouseeareitsshort
falls?
Manufacturersupport Notapplicable
Arethereanyothercritical
factorsintheIPv4/IPv6debate
thathavenotbeenaddressedin
thisquestionnaire?
IPv4maybecomeatradeable
asset
Training,identifywhoneedsIPv6
trainingandwhyisbusinessnot
requiringIPv6
WhatisyourviewonmobileIP? MobileTelcosdontsupportIPv6,
theyshould.
Nocomment




P age | 67

7.6 Final Result
Looking at each successive analysis including the literature review analysis, the
literature analysis (analysis), the questionnaire analysis and the case study analysis I cannot
refute the facts presented here. From a scientific stance one would have to choose IPv6 as the
Internet Protocol of the future!

__________________________________________


















P age | 68

CHAPTER 8 - CONCLUSIONS
8.0 Final Conclusion
In conclusion and looking initially at the literature review; the data taken from the
various protocol specification documents puts IPv6 leagues ahead of IPv4. The software
implementation of IPv6 seen in every day routers, switches and workstations still requires a
little tweaking but this is happening all the time.
The literature analysis draws its data from experiments (some real and some simulated)
carried out by researchers around the world. Going by the research papers referenced in this
thesis one can see that equipment used in the various experiments varies from university to
university; this could impinge on the validity and comparability of the results data.
The results obtained via the questionnaires shows the value of both IPv4 and IPv6; if no
other data were available it would be hard to choose which protocol version is superior. In
making the choice to switch to IPv6 or stay with IPv4 a lot depends on the IPv4 address
resources at the disposal of the organisation and their willingness to invest in IPv6 technology
and training of staff to ensure continued service delivery.
Current news reports (2010) indicate that China is blazing ahead with its role-out of
IPv6; this should be setting off alarm bells for European enterprises that may lose out on
opportunities for new product development. Given that HEAnet and NUIG-(ISS) are both
part of the education sector in Ireland it would be a little more difficult to see what lies ahead
for private enterprise. The majority of private enterprises are dependent on commercial
Internet Service Providers so to carry out a case study on companies such as Eircom, BT
Ireland, O2, Meteor, Vodafone, Verizon Ireland, UPC Ireland, Irish Broadband
Communications or Google Ireland to name but a few of the ISPs that operate in Ireland,
would be quite insightful. There may well be many new product development and
P age | 69

employment opportunities for those who get involved in the creation and delivery of IPv6
goods and services.
8.1 Results in Context
There may be many opportunities for businesses to develop new software for IPv6 or
cash-in on writing software patches for IPv6 incompatible software modules. One particular
area that comes to mind is the software security industry. IPv6 compatible Intrusion
Detection and Firewall solutions will have to be developed. Another area is Quality of
Service protocols for IPv6, these protocol specifications are still in research and may take
some time and effort before they reach industry standards.
It is my wish that this thesis has contributed something to the research field of
communications protocols. One contribution that can be taken from this thesis is the
opportunity to develop Quality of Service (QoS) protocols and software for IPv6 as currently
QoS has limited support in current IPv6 implementations.
Other benefactors of my research may include university IT departments who are still
only teaching IPv4 in computer communication classes, this needs to change as it will add
value to graduates technical degrees if they know about IPv6. There could also be
opportunities here for courses on IT strategy; students can learn about IPv6 in their
networking class and then work on team projects to develop IPv4/IPv6 migration strategies.
The results obtained in this thesis reflect real world issues; in that, here we have a
technology, IPv6 that needs to be adopted within the next few years but existing technologies
IPv4 and NAT are helping to prop-up fiscal barriers-to-entry thus hindering the transition to
IPv6. Irelands current recessionary economy is also playing a role here. It is my educated
opinion that any theory arising from this reported could be applied to the domain of High
Performance Computing, particularly Beowulf Clusters that need to be inter-connected over
P age | 70

high performance networks. Theory from this thesis could also be applied to IT strategy and
IT risk assessment techniques.
There is consensus that global uptake of IPv6 is slow given the imminent depletion of
IPv4 addresses; however there is a lot of research being carried out by major entities
particularly by the US Department of Defence (NASA Research and Engineering Network,
2010) who are realizing the need for more IP addresses to support proliferation of mobile
devices in the battlefield. They have also demanded that their entire network be IPv6
compatible by 2008 (www.nren.nasa.gov). The US space agency NASA is also
experimenting with IPv6. One initial exercise being the establishment in 2003 of the NASA
NREN implemented on an IPv6 network test-bed between NASA Ames Research Centre,
NASA Glenn Research Centre, and NASA Marshall Space Flight Centre (NASA Research
and Engineering Network, 2010, www.nren.nasa.gov). GANT Europes Pan-European
Research and Education network also offers IPv6 connectivity and promotes IPv6 adoption
among its European NREN co-founders (GANT IP, 2010, www.geant.net).
As major players, the majority of whom are state funded, continue to adopt IPv6 then
perhaps regional and local Internet Service Providers may follow suit and share the
advantages of IPv6 with you and me, their end users.
8.2 Identifying Future Work
As part of identifying future work it is important to identify objectives I have not
fulfilled in this thesis. My main objective was to identify what version of Internet Protocol
should be adopted for future use on the Internet and this has been achieved. In this report a
chapter is dedicated to transition mechanisms and I also hint at there being a large time gap
between total IPv6 adoption and turning off of IPv4. What is not discussed and analysed is
how an organisation might make that transition. This is not an easy process and almost
P age | 71

certainly requires development of a dynamic IT strategy. If I had more time to complete this
thesis my efforts would be pursuant to this issue.
With regard to other more external project starting points there would be a wealth of
issues to study. Engineers are still refining aspects of IPv6 and ancillary protocols so there
would be opportunities here for studying new protocols or refining current protocols.
Another issue worth looking at is; what do we do with electronic equipment that cannot
be upgraded to IPv6? Will it just be dumped or could it be given to developing nations etc. If
we transport ourselves twenty years into the future and then look at what remains of the
global IPv4 infrastructure we may see that there is still life in the IPv4 network. The IPv4
network may be suitable to certain types of projects or uses. Also at that future point the
majority of the 4 billion IPv4 addresses may be claimed back by IANA allowing IPv4
infrastructure to flourish again!
There is also a lot of Internet activism associated with promoting IPv6 and many
countries around the world have established an IPv6 taskforce to promote IPv6 and offer
testing and evaluation services to private businesses that may not be able to afford in-house
testing.
This marks the end of the conclusions chapter and it also marks the end of this thesis
project, the following sections contain a reference section and appendices A to E.







P age | 72

References
Amoss, J . J ., & Minoli, D. (2008). Handbook of IPv4 to IPv6 transition, Methodologies for
institutional and corporate networks [PDF]. Available from
http://gigapedia.com/items:links?id=93890
Anttalainen, T. (2003). Introduction to Telecommunications Network Engineering [PDF
version]. Available from http://gigapedia.com/items/8338/introduction-to-
telecommunications-network-engineering--second-edition
Barnes, J . C. (2001). A Guide to Business Continuity Planning. Chichester: Wiley & Sons.
Bates, R. J . (2002). Broadband Telecommunications Handbook [PDF version]. Available
from http://gigapedia.com/items:links?id=3171
Beijnum, I. v. (2006). Running IPv6 [PDF]. Available from
http://gigapedia.com/items:links?id=25219
Berndtsson, M., Hansson, J ., Olsson, B., & Lundell, B. (2008). Thesis Projects: A Guide for
Students in Computer Science and Information Systems (2nd ed.). London: Springer.
Borman, D., Deering, S., & Hinden, R. (1999). IPv6 J umbograms. (RFC 2675). Retrieved
from IETF. Available from http://64.170.98.42/html/rfc2675
Carpenter, B., & J ung, C. (1999). Transmission of IPv6 over IPv4 Domains without Explicit
Tunnels. (RFC2529). Retrieved from IETF. Available from
http://64.170.98.42/html/rfc2529
Cho, K., Luckie, M., & Huffaker, B. (2004). Identifying IPv6 network problems in the dual-
stack world. Paper presented at the NetT '04: Proceedings of the ACM SIGCOMM
workshop on Network troubleshooting., Portland, Oregon, USA.
Comer, D. E. (1999). Computer Networks and Internets (2 ed.). New J ersey: Prentice-Hall.
Deering, S., & Hinden, R. (1998). Internet Protocol, Version 6 (IPv6) Specification. (RFC
2460). Retrieved from IETF. Available from http://www.ietf.org/rfc/rfc2460.txt
P age | 73

Driving IPv6 Deployment. (2010). Retrieved J une 14, 2010, from
http://www.ipv6forum.com/modules.php
Egevang, K., & Francis, P. (1994). The IP Network Address Translator (NAT). (RFC 1631).
Retrieved from IETF. Available from http://64.170.98.42/html/rfc1631
Fenner, W. (1997). Internet Group Management Protocol. (RFC 2236). Retrieved from
IETF. Available from http://www.ietf.org/rfc/rfc2236.txt
Gamess, E., & Morales, N. (2007). Implementing IPv6 at Central University of Venezuela.
Paper presented at the LANC '07 Proceedings of the 4th international IFIP/ACM
Latin American conference on Networking, San J os Costa Rica.
Goncalves, M., & Niles, K. (1999). IP Multicasting: Concepts and Applications [Compiled
HTML version].
Hafner, K., & Lyon, M. (1996). Where wizards stay up late: The origins of the Internet [PDF
version]. Available from http://gigapedia.com/items/253751/where-wizards-stay-up-
late--the-origins-of-the-internet
Hagen, S. (2006). IPv6 Essentials [Compiled HTML]. Available from
http://gigapedia.com/items/8723/ipv6-essentials-1st-edition
Hall, E. (2000). Internet Core Protocols: The Definitive Guide [Complied HTML version].
HEAnet. (2009). HEAnet Services Catalogue [PDF]. Available from
http://www.heanet.ie/sites/default/files/HEAnet%20Services%20Catalogue%2009.pdf
Helal, A., Haskell, B., Carter, J . L., Brice, R., Woelk, D., & Rusinkiewicz, M. (2002). Any
Ttime, Anywhere Computing, Mobile Computing Concepts and Technology [PDF].
Available from http://gigapedia.com/items:links?id=40786
Hinden, R., & Deering, S. (2006). Internet Protocol Version 6 (IPv6) Addressing
Architecture. (RFC 4291). Retrieved from IETF. Available from
http://64.170.98.42/html/rfc4291
P age | 74

Huitema, C. (2006). Teredo: Tunneling IPv6 over UDP through Network Address
Translations (NATs). (RFC 4380). Retrieved from IETF. Available from
http://tools.ietf.org/html/rfc4380
Ismail, M. N., & Abidin, Z. Z. (2009, 3-5 April, 2009). Implementing of IPv6 Protocol
Environment at University of Kuala Lumpur: Measurement of IPv6 and IPv4
Performance. Paper presented at the Future Computer and Communication, 2009.
ICFCC 2009. International Conference on.
ITU-T. (1994). Open Systems Interconnection. Retrieved December 22,, 2009, from
http://www.itu.int/rec/dologin_pub.asp?lang=e&id=T-REC-X.200-199407-I!!PDF-
E&type=items
J ohnson, D. B., Perkins, C. E., & Arkko, J . (2004). Mobility Support in IPv6. Retrieved from
IETF. Available from http://www.ietf.org/rfc/rfc3775.txt
J ohnsn, G., Scholes, K., & Whittington, R. (2008). Exploring Corporate Strategy (8th ed.).
London: Pearson Education.
Kozierok, C. M. (2005). The TCP/IP Guide [PDF version]. Available from
http://gigapedia.com/items/65322/the-tcp-ip-guide--a-comprehensive--illustrated-
internet-protocols-reference
Law, Y.-N., Lai, M.-C., Tan, W. L., & Lau, W. C. (2008, 19-23 May 2008). Empirical
Performance of IPv6 vs. IPv4 under a Dual-Stack Environment. Paper presented at
the Communications, 2008. ICC '08. IEEE International Conference on
McCann, J ., Deering, S., & Mogul, J . (1996). Path MTU Discovery for IP version 6. (RFC
1981). Retrieved from IETF. Available from http://64.170.98.42/html/rfc1981
Mohamed, S. S., Buhari, M. S., & Saleem, H. (2006). Performance comparison of packet
transmission over IPv6 network on different platforms. Communications, IEE
Proceedings, 153(3), 425-433.
P age | 75

Mujinga, M., Muyingi, H., & Rao, G. S. V. R. K. (2006). IPSec overhead analysis in dual
stack IPv4/IPv6 transition mechanisms. Paper presented at the Advanced
Communication Technology, . ICACT 2006. The 8th International Conference
Retrieved from URL:
http://www.ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=1625664&isnumber
=34120
Narayan, S., Kolahi, S. S., Sunarto, Y., Nguyen, D. D. T., & Mani, P. (2008). Performance
comparison of IPv4 and IPv6 on various windows operating systems. Paper presented
at the Computer and Information Technology, 2008. ICCIT 2008. 11th International
Conference on. Retrieved from
http://www.ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=4803056&isnumber
=4802963
Narayan, S., Shang, P., & Fan, N. (2009). Network performance evaluation of Internet
Protocols IPv4 and IPv6 on operating systems. Paper presented at the Wireless and
Optical Communications Networks, 2009. WOCN '09. IFIP International Conference
on. Retrieved from
http://www.ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=5010548&isnumber
=5010495
Narayan, S., & Yhi, S. (2009). Application layer network performance analysis of IPv4 and
IPv6 on Windows operating systems. Paper presented at the Computers and Devices
for Communication, 4th International Conference on Retrieved from
http://www.ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=5407202&isnumber
=5407062
P age | 76

Narten, T., Nordmark, E., Simpson, W., & Soliman, H. (2007). Neighbor Discovery for IP
version 6 (IPv6). (RFC 4861). Retrieved from IETF. Available from
http://64.170.98.42/html/rfc4861
Nordmark, E., & Gilligan, R. (2005). Basic Transition Mechanisms for IPv6 Hosts and
Routers. (RFC4213 ). Retrieved from IETF. Available from
http://tools.ietf.org/rfc/rfc4213.txt
NUIGalway. (2010). About Us. Retrieved 3 of J une, 2010, from
http://www.nuigalway.ie/about-us/who-we-are/our-history.html
NUIGISS. (2010). NUIG On-line service catalogue [Web Page]. Available from
www.nuigalway.ie/information-solutions-and-services/
Parker, T., & Siyan, K. S. (2002). TCP-IP Unleashed [PDF version]. Available from
http://gigapedia.com/items/43829/tcp-ip-unleashed--3rd-edition-
Postel, J . (1981a). Assigned Numbers. (RFC 790). Marina del Rey, CA: USC - Information
Sciences Institute. Retrieved from IETF. Available from
http://www.ietf.org/rfc/rfc790.txt
Postel, J . (1981b). Internet Protocol. (RFC 791). Marina del Rey, CA: USC - Information
Sciences Institute. Retrieved from IETF. Available from
http://www.ietf.org/rfc/rfc791.txt
Sailan, M. K., Hassan, R., & Patel, A. (2009). A Comparative Review of IPv4 and IPv6 for
Research Test Bed Paper presented at the 2009 International Conference on Electrical
Engineering and Informatics. Retrieved from
http://dx.doi.org.libgate.library.nuigalway.ie/10.1109/ICEEI.2009.5254698
Sanguankotchakorn, T., & Somrobru, M. (2005). Performance Evaluation of IPv6/IPv4
Deployment over Dedicated Data Links. Paper presented at the Information,
Communications and Signal Processing, 2005 Fifth International Conference on.
P age | 77

Retrieved from
http://www.ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=1689043&isnumber
=35625
Shiau, W.-L., Li, Y.-F., Chao, H.-C., & Hsu, P.-Y. (2006). Evaluating IPv6 on a large-scale
network. Computer Communications, 29, 3113-3121.
Sportack, M. A. (2002). IP Addressing Fundamentals [Compiled HTML version]. Available
from http://gigapedia.com/items/10186/ip-addressing-fundamentals
Spurgeon, C. E. (2000). Ethernet: The Definitive Guide [PDF version]. Available from
http://gigapedia.com/items/8036/ethernet---the-definitive-guide
Srisuresh, P., & Egevang, K. (2001). Traditional IP Network Address Translator (Traditional
NAT). (RFC 3022 ). Retrieved from IETF. Available from
http://www.ietf.org/rfc/rfc3022.txt
Templin, F., Gleeson, T., & Thaler, D. (2008). Intra-Site Automatic Tunnel Addressing
Protocol. (RFC 5214). Retrieved from IETF. Available from
http://tools.ietf.org/html/rfc5214
Wang, Y., Ye, S., & Li, X. (2005). Understanding current IPv6 performance: a measurement
study. Paper presented at the ISCC 2005. Proceedings. 10th IEEE Symposium on.
Retrieved from
http://www.ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=1493709&isnumber
=32117
Wegner, J . D., & Rockell, R. (2000). IP Addressing and Subnetting, Including IPv6
[Complied HTML version]. Available from http://gigapedia.com/items/13527/ip-
addressing-and-subnetting--including-ipv6
P age | 78

Wu, T. Y., Chao, H. C., Tsuei, T. G., & Li, Y. F. (2005). A measurement study of network
efficiency for TWAREN IPv6 backbone. International Journal of Network
Management, 15(6), 411-419.
Zeadally, S., Wasseem, R., & Raicu, I. (2004). Comparison of end-system IPv6 protocol
stacks. Paper presented at the Communications, IEE Proceedings. Retrieved from
http://www.ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=1309776&isnumber
=29069


















P age | 79

APPENDICES
Appendix A Questionnaire completed by Gareth Eason of HEAnet
SECTION 1 GENERAL
Do you consider your current IPv4 address resources scarce? Currently have just over a /12
for HEAnet usage, and we route the IP address space of our clients, several of whom would
have a /16 or larger.
Would you consider using Network Address Translation (NAT) on your network? We do not
use NAT (in the sense of the question asked) but that we are considering it as a migration
strategy towards IPv6. From our analysis it is not a solution though and it causes many
problems if it were to be the solution, rather than just a migratory step.
Do you plan to acquire further IPv4 address resources? Yes and No. Only if our clients
request it. One of HEAnets services is to act as a LIR, so we will continue to act as a Local
Internet Registry (LIR) as long as we have IPv4 resources to give out.
SECTION 2 COST
What is the average length of HEAnets IT upgrade cycle? 5 years. Only items deemed to be
in need of an upgrade will be changed.
Do you have a formal budget for IPv6 deployment? Give reasons for your answer. We
currently run an IPv6 network (dual stacked) and as such our budget for all devices, services,
etc. must include IPv6 as well as IPv4.
Have you incorporated IPv6 deployment in your IT upgrade cycle? Give reasons for your
answer. Yes. IPv6 is seen as just another protocol so tenders for new networking kit would
include a requirement to support IPv6.
P age | 80

What have been the major financial hurdles in IPv6 deployment? Vendors engaging in
product differentiation and charging extra for including IPv6 capability in their products, and
we later find that some new products do not fully support IPv6.
In the context of COST, what would you like to see happen with regard to IPv4/IPv6 issues
and benefits? For product vendors to stop engaging in product differentiation when it comes
to IPv6 capabilities.
Do you think the Government should provide financial assistance with regard to IPv4/IPv6
issues and benefits? No, the market is healthy enough to not require government intervention.
We may like to see government regulation/intervention to further promote IPv6 adoption.
SECTION 3 STRATEGY
What is your IT strategy in the context of IPv4 and IPv6? Dual stack our core network,
encourage our clients to move to IPv6, for those who cannot perhaps due to legacy
equipment, we may provide carrier grade NAT for them. We hope to be an IPv6 only
network by 2013.
What role does IPv6 play in the alignment of your IT and business strategy? We run a dual
stack network at the moment and all newly purchased products must be IPv6 compliant.
Do you see IPv6 playing a role in your business continuity plan (BCP)? Give reasons for your
answer. Yes. Given that one of our business services is to act as a LIR we need to adopt IPv6
because some day in the future we will not be able to give out anymore IPv4 addresses. But if
and when we run out of IPv4 address space it's likely everyone else will too (excepting
hoarding, etc.) - so it's about fundamentally making not only our work possible into the
future, but also that of our clients who need address space to run projects, test platforms and
P age | 81

research infrastructures.
Do you see IPv4 address depletion as a threat to the alignment between your IT and business
strategy? Not in HEAnet we have already dealt with this, but for our clients we see it as a
threat to them. Really I'm just guessing that our clients might be considering the change a
threat to themselves internally. There are very real risks associated with trying to get an
institution with a whole MIS infrastructure, probably many labs of computers and then all the
staff computing facilities and interconnecting equipment to all play nicely with one and other
in a change such as this.
In the context of a PESTEL analysis can you list factors you deem important when assessing
IPv4 and IPv6 under the following headings?
Political The US government and US Department of Defence (DoD) have stated that
all new networking equipment produced by manufacturers must be IPv6
compliant. This has helped push the market to adopt IPv6 products as
opposed to waiting for the consumer market to make demands on
manufacturers which may never happen.
Economic This is where the vicious circle exists. Customers dont see need for IPv6
products so manufacturers dont see the need to produce them. Deploying
IPv6 is seen as a cost sink. Average home users do not see the negative
impact NAT has on their Internet experience.
Social Home users do not see the need for IPv6 but if their favourite content was to
become available only via IPv6 such as face-book or you-tube we would see
a customer demand for IPv6 connectivity.
P age | 82

Technological It is difficult to recover R&D cost at the moment due to lack of demand for
IPv6 products. ISPs currently have stable networks and given that IPv6
technology is roughly 10 years old and parts of it are still in testing ISPs are
slow to adopt it.
Environmental From a green perspective IPv4/IPv6 maybe cost neutral. You could argue
that having a dual stacked network and carrier grade NAT may produce
more energy consumption as opposed to being a 100% IPv6 network.
Legal factors There may be issues about lawful interception and traceability. Currently
many security products such as firewalls, net-flow and anomaly detection
products do not support IPv6 or do not support it fully which creates a
security issue for the IPv6 network.
In the context of Strengths, Weaknesses, Opportunities & Threats (SWOT) analysis of IPv4,
can you list factors under each heading that IPv4 brings to your business?
Strengths IPv4 is secure, well understood and well supported.
Weaknesses Lack of address space in IPv4, NAT and RFC1918 address space.
Opportunities Maybe setting up of gateways to cater for those who cannot adopt IPv6. It is
easy to hire graduates with IPv4 experience; familiarity with IPv6 is a lot
lower among graduates.
Threats IPv4 address depletion, NAT breaks the end-to-end network model.
In the context of Strengths, Weaknesses, Opportunities & Threats (SWOT) analysis of IPv6,
can you list factors under each heading that IPv6 brings to your business?
Strengths Address space and scalability
P age | 83

Weaknesses Support is limited at the moment; routing equipment doesnt support all
features of IPv6. There is a lack of understanding about the IPv6 address
format they are perceived as being totally different to IPv4 addresses.
Opportunities Manufacturers could provide better support. Service providers such as
Google could make content available only over IPv6 this would drive
consumer demand IPv6.
Threats IPv6 looks very different from IPv4 but it isnt. New electronic devices do
not support IPv6 as much as they should.
SECTION 4 INNOVATION
Given the Irish governments commitment to innovation and creativity in education and
research. Do you see IPv4 and IPv6 being able to provide the environment within which
innovation systems can be born? Outline the pros and cons of IPv4 and IPv6 in this context.
University research groups are working on IPv4 and IPv6 so HEAnet needs to provide
connectivity for them.
SECTION 5 TECHNICAL
Does your IPv4 network use Quality of Service (QoS)? Yes and No. QOS is not used in our
core network. QoS is achieved through the human management of our network. Using QoS
reduces the overall QoS of traffic flows due to the packet tagging and scanning required in
QoS. It is used on some client links where there is a higher proportion of jitter sensitive
traffic.
According to the latest IPv6 specification (RFC-2460, 1998) QoS in IPv6 is still very much
experimental. How do you react to this? If we continue with our policy of not using QoS we
P age | 84

will not be affected. However we would like to have the option of using QoS in IPv6 if the
need arose.
Given that IPv6 requires at least 1280 bytes (but recommended 1500 bytes) Maximum
Transmission Unit (MTU) size on every link; can you outline some pros and cons associated
with this? Sometimes this is an issue, we manage our own layer 1 and 2 network so we have
control over the MTUs and try to use jumbo frames mostly, but if we connect into a
managed link provided by BT or Eircom etc, we have to be careful to ensure we match the
MTU on the managed link.
From a security perspective how do you safeguard your IPv4 and IPv6 network? In the IPv4
network we use Netflow and monitor for trends and anomaly detection. Until recently we
couldnt monitor IPv6 due to a lack of support in our monitoring software for IPv6. Our
existing tool set for monitoring IPv4 wasnt suitable for monitoring IPv6 so we had to
investigate other products. Also firewalls are not used on the core network, it becomes very
expensive to firewall multiple 10Gb/s streams, but client institutions can use them if they
wish. Note also that many firewall solutions do not support IPv6 Comments from Paul
Mullen on the HEAnet schools team: From a security perspective for IPv4 we have a
centralised firewall a Cisco 6500 Firewall Services module (FWSM), all customers on the
schools network are behind this firewall. At each school the Customer Premises Equipment
(CPE) a Cisco 871 has an Access Control List (ACL) that blocks what comes into and what
goes out of the school. In relation to IPv6, we dont have IPv6 on the schools network so
there is no need to do IPv6 blocking. Even though HEAnet has a dual stacked core network,
the schools net will not have IPv6 for the near future because the CPE Cisco 871 doesnt
really support IPv6. On the new 100Mb/s schools network we use IPv4 and we plan to use
P age | 85

IPv6 on this network. Schools network traffic is transported as Point to Point over Ethernet
(PPoE) and is aggregated by commercial ISPs such as Eircom and BT. The schools traffic
then lands on an aggregation router in the HEAnet core. Also note that commercial ISPs are
still using IPv4 in their core networks so this hinders us from running IPv6 to the CPE in the
various schools directly.
Research has shown that IPv6 impacts to a greater extent the Central Processing Unit (CPU)
performance of end user workstations when compared to IPv4. How do you respond to this?
Effectively, while the CPU is impacted more with IPv6 than IPv4, that's not only to be
expected, but gives greater return for the investment (of CPU cycles) and is something that
can and I expect will be optimised in the future such that I fully expect to see IPv4 imposing
a greater penalty on CPUs than IPv6 in the near future.
Have you talked with your software/hardware vendors to see if they offer IPv6 compatible
products? What response have you had? Yes. All our tender requirements state that products
must (with very limited exceptions) support IPv6.
Where do you see IPv4 and IPv6 in the technical future of HEAnet? More and more IPv6
coming online, we had more clients request IPv6 connectivity this year. We expect to see a
decline in requests for IPv4 in the future.
In your experience with IPv6 what do you see are its short falls? Manufacture support but this
is changing.
Are there any other critical factors in the IPv4/IPv6 debate that have not been addressed in
this questionnaire? Not that I can think of, perhaps IPv4 may start to become a trade-able
asset as it becomes more sparse.
P age | 86

What are your views on mobile IP? Mobile Telcos in the early days adopted IPv6 for use on
their network but now they seem to be sticking with IPv4.






















P age | 87

Appendix B Questionnaire completed by Tom Regan of NUIG ISS
SECTION 1 - GENERAL
Do you consider your current IPv4 address resources scarce? No! We have a /16 address
range.
Do you use Network Address Translation (NAT) on your network? Yes! We use a lot of it in
our computer suites but not on the wireless networks or in the DMZ.
Do you use Classless Inter-Domain Routing (CIDR) on your network? Yes! We use a mix of
CIDR and VLSM.
Do you plan to acquire further IPv4 address resources? No!
Have you or do you plan to acquire IPv6 address resources? No!
Is any portion of your network IPv6 ready? No! But all new network gear is required to be
IPv6 capable. All of our network gear is CISCO and the core network would be IPv6 capable.
SECTION 2 COST
What is the average length of your organisations IT upgrade cycle? This is budget dependent.
The PC suites are upgraded every 4 years, the rest of the network is not so lucky. We still
have some 10Mb/s switches in our network.
Do you have a formal budget for a future IPv6 deployment? No!
Do you plan to incorporate IPv6 deployment in your next IT upgrade cycle? No! This would
be budget dependent but we do require all new gear to be IPv6 capable.
What do you foresee as the major financial hurdles to IPv6 deployment? The training of staff
in service delivery and the training of management to dispel the misinformation about IPv6.
P age | 88

In the context of COST, what would you like to see happen with regard to IPv4/IPv6 issues
and benefits? Training for everyone involved in the potential acquisition and delivery of IPv6
services.
Do you think the Government should provide financial assistance with regard to IPv4/IPv6
issues and benefits? Yes! Financial assistance could be given to support training etc.
SECTION 3 STRATEGY
What is your IT strategy in the context of IPv4 and IPv6? Our strategy is IPv4 only. We use
private RFC1918 addressing and layer 3 routing.
Do you see IPv6 playing a role in your business continuity plan (BCP)? No! We have plenty
of IPv4 addresses so we are not worried.
Do you see IPv4 address depletion as a threat to the alignment of your IT strategy with your
business strategy? No! Maybe in research areas but not in general business requirements.
In the context of a PESTEL analysis can you the list factors you deem important when
assessing IPv4 & IPv6 under the following headings?
Political US Government announcement that all new networking gear added to
government networks must be IPv6 compliant.
Economic The cost benefit of implementing IPv6 should also take account of staff
time spent on IPv6 projects, given the current government demand for 9%
reduction in staff or 9% increase in productivity IPv6 will be a very hard
sell.
Social Ubiquitous computing having all the devices in your home IPv6 enabled
Technological Trying to sell the technological advantages of IPv6 to management will be
P age | 89

difficult.
Environmental If IPv6 could say it offered a green advantage it would be a good selling
point.
Legal factors No comment.
In the context of Strengths, Weaknesses, Opportunities & Threats (SWOT) analysis of IPv4,
can you list factors under each heading of SWOT that IPv4 brings to your business?
Strengths There is a lot of familiarity with IPv4 in student groups and organisations.
Weaknesses By using NAT we lose some visibility. NAT also requires extra processing
power to run additional protocols and to keep translation tables up to date.
NAT also breaks certain functionality and also has a lack of addresses.
Opportunities IPv4 has been improved with DHCP, NAT and logging of NAT tables has
helped from a security aspect.
Threats Security is weak in IPv4, ARP poisoning.
In the context of Strengths, Weaknesses, Opportunities & Threats (SWOT) analysis of IPv6,
can you list factors under each heading of SWOT that IPv6 brings to your business?
Strengths More IP addresses and better security.
Weaknesses Staff will need to be trained and made familiar with IPv6. Switch from
something that works OK (IPv4) to something that has a lot of uncertainty
associated with it (IPv6) will be a hard sell to management. Integration with
applications.
Opportunities Mobility, more devices can connect to the network. There may be
P age | 90

opportunities for research e.g. in places like DERI but NUIG have not seen
a demand for this yet.
Threats Low integration with other institutions, software applications run by staff
and students may be affected by IPv6. Internet connectivity to the IPv4
network. For example most library services require a static IP address to
match against for license requirements.
SECTION 4 INNOVATION
Given the Irish governments commitment to innovation and creativity in research and
education. Do you see IPv4 and IPv6 being able to provide the environment within which
innovation systems can be born? Outline the pros and cons of IPv4 and IPv6 in this context.
What is in IPv6 that is not in IPv4? If we could identify the parts of IPv6 that are suited to
innovation this could be a selling point. Also if we are not doing innovation in IPv6 then Irish
companies cannot get involved in contracts from the US government.
SECTION 5 TECHNICAL
Does your IPv4 network use Quality of Service (QoS)? Yes! Specifically to help video
conferencing and Voice Over IP (VOIP)
According to the latest IPv6 specification (RFC-2460, 1998) QoS in IPv6 is still very much
experimental. How do you react to this? We use one vendor CISCO so we would look to
them to provide the answers to this.
Given that IPv6 requires at least 1280 bytes (but recommended 1500 bytes) Maximum
Transmission Unit (MTU) on every link, do you see this causing an issue for your current
network infrastructure? No! We use 100% Ethernet and some Virtual Private Networks
P age | 91

(VPNs) to buildings off the main campus.
From a security perspective how do you safeguard your IPv4/IPv6 network? DHCP
snooping, firewalls and proxy.
Research has shown that IPv6 impacts to a greater extent the Central Processing Unit (CPU)
perform user workstations when compared to IPv4. How do you respond to this? We have a
budget to upgrade the PC suites every 4 years so this may not be an issue.
Have you talked with your software/hardware vendors to see if they offer IPv6 compatible
products? What response have you had? Not really, but CISCO have advertised to NUIG that
their gear does IPv6 and all new tenders would require IPv6 capabilities.
Where do you see IPv4 and IPv6 in the future of NUIG? I cannot see any changes in IPv4 in
the medium term, there may be a niche area in research etc maybe setting up an IPv6 lab.
Are there any other critical factors in the IPv4/IPv6 debate that have not been addressed in
this questionnaire? Training and analysing what training would be required and for who and
also why arent business requesting IPv6.
Can you make a few comments on mobile IP in the context of IPv4/IPv6? No comment








P age | 92

Appendix C Thesis Process Evaluation
I started work on this thesis in October 2009 when I meet with my class mates and
coordinator Pat Byrne for a research day on the NUIG campus. This meeting helps one
formulate thesis ideas and objectives. It was at this research day that I had made a mistake
with my initial research proposal. I was going to propose that IPv4 is about to die and we
should move to IPv6 as soon as possible. This approach of course rules out any scientific
investigation to assess IPv4 against IPv6. I was glad I had discovered this error so early on in
my project.
Another small and minor error I made was in the submission of the thesis term paper
due in J anuary 2010. When I started writing my thesis I decided to start from the beginning as
in write the title page, abstract, and then a history and introduction to the Internet and IPv4. I
did not communicate my writing strategy to my thesis supervisor who on receipt of the term
paper was a little unsure as to what I was doing. I think as advice to others; always ensure
your thesis supervisor knows your plan of action.
Chatting regularly with your thesis supervisor is very important but I found that these
meets were good up to a point. They are a good way of providing general guidance but if a
student requires fine details (In my case I did) it would be unfair to constantly bug your
supervisor with a constant stream of questions. So I got a book called Thesis Projects: A
Guide for Students in Computer Science and Information Systems, and it was a blessing to
have. I actually got 3 different guide books just to insure they were all giving the correct
advice. I would recommend to all thesis students that you get yourself a good guide book,
maybe your supervisor can recommend one!
Another good idea I had was in relation to the questionnaire. I searched for
questionnaires using Google which helped me develop questions I could tailor for my own
P age | 93

questionnaire. According to research best practices it is beneficial to pose similar questions to
different cohorts in a particular problem domain.
All in all I enjoyed the process of completing my Masters thesis and I would
encourage anyone thinking of doing a Masters in IT to go do it at NUIG, staff are very
professional and affable to boot.




















P age | 94

APPENDIX D - List of Figures
Figure: 1 The OSI model showing logical and actual data flows
Figure: 2 The Ethernet V2 frame
Figure 3 IPv4 address hierarchy
Figure 4 An Ethernet frame encapsulating Layer 3 and above
Figure 5 The IPv4 header as defined in RFC 791
Figure 6 MTU size comparisons of Layer 2 technologies
Figure 7 IP Routing and Delivery between networks
Figure 8 IPv6 unicast address allocation
Figure 9 Link-local unicast address
Figure 10 Global unicast address
Figure 11 IPv6 encapsulation
Figure 12 IPv6 Header and Extension headers
Figure 13 IPv6 Multicast address format
Figure 14 Network Address Translation (NAT)
Figure 15 Network Address Port Translation (NAPT)
Figure 16 Dual stack IPv4 & IPv6
Figure 17 Mobile IPv4 operation
Figure 18 Mobile IPv6 call processing
Figure 19 Growth of the IPv4 BGP table
Figure 20 Wavelength Division Multiplexing in the range 230.6 to 187.5GHz
Figure 21 HEAnet National 10Gb/s Fibre Network



P age | 95

APPENDIX E - List of Abbreviations
AH Authentication Header
APNIC Asia Pacific Network Information Centre
ARIN American Registry for Internet Numbers
ARP Address Resolution Protocol
ARPANET Advanced Research Project Agency Network
ASCII American Standard Code for Information Interchange
BGP Border Gateway Protocol
CBR Constant Bit Rate
CIDR Classless Inter-domain Routing
CN Correspondent Node
COA Care Of Address
CPU Central Processing Unit
CWDM Coarse Wavelength Division Multiplexing
DHCP Dynamic Host Configuration Protocol
DNS Domain Name System
DSL Digital Subscriber Line
DWDM Dense Wavelength Division Multiplexing
EBCDIC Extended Binary Coded Decimal Interchange Code
ESP Encapsulating Security Payload
FA Foreign Agent
FCS Frame Check Sequence
FDDI Fibre Distributed Data Interface
FLSM Fixed Length Subnet Mask
FTP File Transfer Protocol
GB/s Giga Bytes per Second
GHz Giga Hertz
GUI Graphical User Interface
HA Home Agent
HEAnet Higher Education Authority network
HTTP Hyper Text Transfer Protocol
HTTP Hyper Text Transfer Protocol
IANA Internet Assigned Numbers Authority
ICT Information Communications Technology
IETF Internet Engineering Task Force
IGMP Internet Group Message Protocol
IHL Internet Header Length
IP Internet Protocol
IPSEC IP Security
IPv4 Internet Protocol version 4
IPv6 Internet Protocol version 6
P age | 96

ISATAP Intra-Site Automatic Tunnel Addressing Protocol
IT Information Technology
ITU-T International Telecommunications Union- Telecoms
Kb Kilo bit
MAC Media Access Control
MAN Metropolitan Area Network
MB Mega Bytes
Mbps Mega bits per second
MN Mobile Node
MPEG Motion Picture Expert Group
MRTG Multi Router Traffic Grapher
MTU Maximum Transmission Unit
NAPT Network Address Port Translation
NAT Network Address Translation
NDP Network Discovery Protocol
NREN National Research & Education Network
NTP Network Time Protocol
ISS Information Solutions & Services
OSI Open Systems Interconnect
PPP Point to Point Protocol
RA Router Advertisement
RFC Request For Comment
RIPE Rseaux IP Europens
RTT Round Trip Time
SSL Secure Socket Layer
TCP/IP Transmission Control Protocol / Internet Protocol
TEP Tunnel End Point
UDP User Datagram Protocol
UDP User Datagram Protocol
VLSM Variable Length Subnet Mask
VOIP Voice Over IP
WDM Wave Division Multiplexing

Você também pode gostar