into the future with ipv4 or ipv6?

8/12/2019 Into the Future With IPv4 or IPv6?

1/104

Into the future with IPv4 or IPv6?

Kevin F. Doyle BA (Psychology & Information Technology)

email: [email protected]

web: ie.linkedin.com/in/kdcod

Discipline of Information Technology

College of Engineering and Informatics

NUI Galway

Ireland

2010


2/104

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.4x1038IP 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.


3/104

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, Joan, Susanne, John and Barbara), and my

friends for providing support when needed.

Dedication

This work is dedicated to my parents Frank & Joan Doyle.


4/104

TABLE OF CONTENTS

PAGE

CHAPTER1-INTRODUCTION

1.0 Thesis Topic - Internet Protocol Version 4 & 6

1.1 Chapter Summary

CHAPTER2-RESEARCHAPPROACHANDRATIONALE

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

CHAPTER3-LITERATUREREVIEW

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


5/104

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


6/104

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

CHAPTER4-LITERATUREANALYSIS

4.0 Introduction

4.1 Throughput

4.2 Round Trip Time, Jitter & 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

CHAPTER5-CASESTUDY

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


7/104

PAGE

CHAPTER6-QUESTIONNAIREANDINTERVIEWDESIGN

6.0 Introduction

6.1 PESTEL

6.2 SWOT

6.3 BCP

6.4 Questionnaire Structure

6.5 Interview Structure

6.6 Chapter Summary

CHAPTER7-RESULTSANDANALYSIS

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

CHAPTER8-CONCLUSIONS

8.0 Final Conclusion

8.1 Results in Context

8.2 Identifying Future Work

References

APPENDICES

Appendix AQuestionnaire to Gareth Eason of HEAnet

Appendix BQuestionnaire 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


8/104

PAGE

Appendix C Thesis Process Evaluation

Appendix D - List of Figures

Appendix E - List of Abbreviations

89

91

92


9/104

P a g e | 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 drivenby 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.4x1038IP 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


10/104

P a g e | 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 andabbreviations 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.


11/104


12/104

P a g e | 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 forthis 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


13/104

P a g e | 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 (232). 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.4x1038(2128) unique IP addresses to exist.

Judgment Dayor 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


14/104

P a g e | 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 ForComment (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 theLiterature Review, where

IPv4, IPv6 and associated technologies are described.


15/104

P a g e | 7

CHAPTER3-LITERATUREREVIEW

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

Johnson 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


16/104

P a g e | 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-developedthe 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


17/104

P a g e | 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 coppercable, 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)


18/104

of the

commu

address

the for

the Fra

transmi

frame.

point c

deman

vast di

frame r

payloa

IP con

T

fragme

address

32-bit I

t the heart

thernet fra

nicating tra

of the rece

at of the d

e Check

ssion error

t this stage

mmunicati

that infor

tances. Thi

eaches its d

section, t

ectivity is

3.23 Layer

he Networ

tation of I

size. (Spu

P address a

of Etherne

e as follo

nsceivers,

iver and se

ata carried

equence is

. Figure 2

igure: 2 T

it is impor

on betwee

ation be i

s situation i

estination t

e IP packet

stablished.

3 (Networ

layer of t

packets. I

geon, 2000

nd 48-bit E

is the Ethe

s: (1) The

2) the 48 b

der respec

in the payl

used to car

shows the l

e Ethernet

ant to unde

two netw

telligently

s handled

he receivin

is then pas

)

e OSI mod

Pv4 uses a

) points ou

thernet add

rnet frame;

Preamble

it Destinati

tfully, (3) t

ad field, (4

ry the resul

atest imple

2 frame S

rstand that

rk nodes at

routed thro

y layer 3, t

node extr

sed up to L

el is respon

IP addres

that ...in

ress. Howe

(Spurgeon

ield is used

on and Sou

e Type/Ve

) the actual

t of the FC

mentation (

ource: (Sp

layer 1 and

any one ti

gh many i

he Networ

acts the IP

ayer 3 the

sible for fo

size of 32

given co

ver it does

, 2000) des

to synchro

ce address

rsion field

Payload D

to aid in

Version 2)

rgeon, 200

layer 2 onl

e, practic

termediar

layer. Wh

acket fro

etwork la

matting, a

bits while I

puter it is

't know the

P a

ribes the e

nise

are the Eth

s used to i

ata and fin

etection of

of the Ethe

0)

y facilitate

l situations

nodes and

en an Ether

the frame

er. This is

dressing a

Pv6 uses a

ware of (it

Ethernet

g e | 10

lements

ernet

dicate

lly (5)

rnet

point to

over

et

here

d

128 bit

s own)


19/104

P a g e | 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


20/104

P a g e | 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 responsibilitiesof 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).


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).


21/104

P a g e | 13


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.


To create an IPv4 address space hierarchy, IPv4 addresses have a network and hostaddress 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)


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.


22/104

P a g e | 14

Figure 4An 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 5The 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.


23/104

P a g e | 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)


As articulated in (Postel, 1981b) the smallest legal datagram size is 576 bytes andadditionally:

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)


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.


24/104

Figu

of netw

be able

networ

link. T

A sum

f

F

L

l

i

a

2

indepe

networ

e 6MTU s

3.36 IPv4

s IP packet

orks each

to be brok

. These fra

is process

ary of poi

hen fragm

agment onl

ield, More

ength Field

cation, rel

ternet iden

dress, and

)

eeping in

dent entity

routes; thi

ize compar

ragmentat

s are sent o

uilt on a v

n into sma

gments the

s handled

ts are take

entation oc

y. The fiel

ragments

and Heade

tive to the

ification fi

the protoc

ind that o

and can be

s concept i

isons of La

ion

ut over the

riety of La

ler parts to

n need to b

y the frag

from (Po

urs, some

s which m

lag, Frag

r Checksu

eginning

eld (ID) is

l fields, to

ce an IP pa

directed se

s called dat

er 2 techn

Internet th

er 2 techn

overcome

reassembl

entation

tel, 1981b)

options are

y be affect

ent Offset,

... The Fra

f the origi

sed togeth

dentify da

cket has be

parately fr

gram inde

logies Sou

y will have

logies, the

ifferent M

ed in seque

echanism i

illustrates

copied, but

ed by frag

Internet H

gment Off

al un-frag

er with the

agram frag

en fragme

m its siste

endence a

rce: (Park

to traverse

efore an I

TU sizes e

nce at the

IPv4.

ow fragm

others re

entation i

ader Leng

et field ide

ented data

source and

ents for r

ted each fr

fragments

outlined i

P a

r & Siyan,

a diverse

packet ne

countered

ther end o

ntation wo

ain with th

clude: Opt

h Field, To

tifies the f

gram... The

destination

assembly.

gment bec

over differ

(Postel, 1

g e | 16

2002)

ixture

ds to

n each

the

rks:

first

ons

tal

agment

(pp. 23-

omes an

nt

81b).


25/104

P a g e | 17


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 7IP 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).


26/104

P a g e | 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.


27/104

P a g e | 19


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).


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 binaryaddress, 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.


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


28/104

a

L

s

p

a

fi

i

T

of IPv6

hierarc

an iden

address

so have m

ocal addres

ch as auto

esent R

dresses to

gure 9)

terface. (p

he next typ

packets an

ically-stru

tifier of a li

of the inte

3.43 IPv6

Fig

Figure

Figur

ltiple IPv6

ses are des

atic addre

uters must

other links

here the i

. 5-11)

e of IPv6 a

d illustrate

tured) val

nk within t

face as out

ncapsulati

re 11IPv6

9 Link-loc

10 Global

addresses

gned to be

ss configur

not forwar

Link-Lo

terface ID

dress is th

in figure 1

e assigned

e site, and

lined by (H

on and For

encapsulat

l unicast a

unicast ad

f any type

used for ad

ation, neig

any pack

al address

s (usually

global un

0. The glo

to a site (a

the interfa

inden & D

matting

ion Source:

dress Sour

ress Sourc

(unicast, a

dressing o

bour disco

ts with Lin

s have the

rafted) fro

cast addres

al routing

cluster of s

e ID is usu

ering, 200

(Deering

ce: (Hinde

e: (Hinden

ycast, and

a single li

ery, or wh

k-Local so

following

the MA

s used for

refix is a (

bnets/link

ally crafted

).

Hinden, 1

& Deerin

& Deering,

P a

ulticast)

k for purp

en no route

rce or dest

ormat (as p

address of

very day r

typically

s), the subn

from the

998)

, 2006)

2006)

g e | 20

Link-

ses

rs are

nation

er

the

uting

et ID is

AC


29/104

P a g e | 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 itspackets, 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


30/104

P a g e | 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 12IPv6 Header and Extension headers Source: (Deering & Hinden, 1998)


(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 1500bytes. 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 Jumbo-grams;

these are packets with a payload larger than 65,535 bytes. Jumbo-grams are achieved through


31/104

P a g e | 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.


(McCann, Deering, & Mogul, 1996) recommend thatevery link in an IPv6 internet

have an MTU of 1280 bytes and where data-grams may need to be encapsulated an MTUconfiguration 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.


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).


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


32/104

P a g e | 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


33/104

P a g e | 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) andNetwork 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


34/104

P a g e | 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 thesenetworks 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/26where 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


35/104

P a g e | 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 14Network 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


36/104

P a g e | 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 15Network 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.


37/104

P a g e | 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 ofthe 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 16Dual 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


38/104

P a g e | 30

decisions in the node are based on the IP header Versionfield for packets that are

received from the lower layers, a Versionfield 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 acquiretheir 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 & Jung, 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


39/104

P a g e | 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 &

Jung, 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.


40/104

P a g e | 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 behindone 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


41/104

P a g e | 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.


42/104

P a g e | 34

Figure 17Mobile 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 (Johnson, 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-arrangedsecurity 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 coexistefficiently with routers that perform "ingress filtering",

d. The IPv6 Neighbour Un-reach ability Detection assures symmetric reach abilitybetween the mobile node and its default router in the current location,


43/104

P a g e | 35

e. Most packets sent to a mobile node while away from home in mobile IPv6 are sentusing 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 NeighbourDiscovery 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 mobileIPv6 to manage "tunnel soft state",

h.

The dynamic home agent address discovery mechanism in mobile IPv6 returns asingle reply to the mobile node; the directed broadcast approach used in IPv4 returns

separate replies from each home agent.

(pp. 5-6)

(Johnson, 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 iscurrently 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


44/104

P a g e | 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 homeagent 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.


45/104

P a g e | 37

Figure 18Mobile 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 aLiterature Analysis.


46/104

P a g e | 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


47/104

P a g e | 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 IPv4throughput, 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


48/104

P a g e | 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. Jitter according to (Bates,

2002) is: Jitter (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.,


49/104

P a g e | 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 lowercompared 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


50/104

P a g e | 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, Jitter 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


51/104

P a g e | 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, theWindows 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:


52/104

P a g e | 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. Jitter 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 decodinguses 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 200

into the future with ipv4 or ipv6?

Documents