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
Abstract In the early 1990’s 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.4x1038 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, Joan, Susanne, John and Barbara), and my friends for providing support when needed.
Dedication This work is dedicated to my parents Frank & Joan Doyle.
TABLE OF CONTENTS PAGE CHAPTER 1 - INTRODUCTION
1
1.0 Thesis Topic - Internet Protocol Version 4 & 6
1
1.1 Chapter Summary
2
CHAPTER 2 - RESEARCH APPROACH AND RATIONALE
3
2.0 Introduction
3
2.1 Literature Review Rationale
3
2.2 Literature Analysis Rationale
3
2.3 Case Study Rationale
4
2.4 Questionnaire Rationale
4
2.5 Research Hypothesis
4
2.6 Chapter Summary
6
CHAPTER 3 - LITERATURE REVIEW
7
3.0 Introduction
7
3.1 Origins of the Internet and Internet Protocol
7
3.2 The OSI 7-Layer Reference Model
8
3.21 Layer 1(Physical)
9
3.22 Layer 2 (Data Link)
9
3.23 Layer 3 (Network)
10
3.24 Layer 4 (Transport)
11
3.25 Layer 5 (Session)
11
3.26 Layer 6 (Presentation)
12
3.27 Layer 7 (Application)
12
3.3 Internet Protocol Version 4 (IPv4)
12
PAGE 3.31 IPv4 Addressing
13
3.32 IPv4 Address Classification
13
3.33 IPv4 Encapsulation & Formatting
13
3.34 IPv4 Datagram Size
15
3.35 IPv4 Maximum Transmission Unit (MTU)
15
3.36 IPv4 Fragmentation
16
3.37 IPv4 Delivery & Routing
17
3.38 IPv4 Multicasting
18
3.4 Internet Protocol Version 6 (IPv6)
19
3.41 IPv6 Addressing
19
3.42 IPv6 Address Classification
19
3.43 IPv6 Encapsulation & Formatting
20
3.44 IPv6 Datagram Size
22
3.45 IPv6 Maximum Transmission Unit (MTU)
23
3.46 IPv6 Fragmentation
23
3.47 IPv6 Delivery & Routing
23
3.48 IPv6 Multicast
24
3.5 Future Proofing IPv4
25
3.51 IPv4 Sub-netting or Fixed-Length Subnet Masks (FLSM)
25
3.52 IPv4 Variable Length Subnet Mask (VLSM)
26
3.53 IPv4 Classless Inter-Domain Routing (CIDR)
26
3.54 Network Address Translation (NAT)
27
3.55 Network Address, Port Translation (NAPT)
28
3.6 Parallel Internets IPv4 & IPv6
29
PAGE 3.61 Dual Stack IPv4 & IPv6
29
3.62 IPv6 Tunnelling
30
3.63 Transmission of IPv6 over IPv4 Domains (6over4)
30
3.64 Transmission of IPv6 Domains to IPv4 Clouds (6to4)
31
3.65 ISATAP Intra-Site Automatic Tunnel Addressing Protocol
31
3.66 Teredo Tunnelling
32
3.7 Mobile IP
32
3.71 Mobile IPv4
32
3.72 Mobile IPv6
34
3.8 Chapter Summary
37
CHAPTER 4 - LITERATURE ANALYSIS
38
4.0 Introduction
38
4.1 Throughput
38
4.2 Round Trip Time, Jitter & Packet Loss Rate
40
4.3 Performance & Operating System (OS) Dependence
43
4.4 Application Performance (FTP, HTTP, VOIP, IPSec)
46
4.5 Scalability
47
4.6 Comparative Summary of Literature Review and Literature Analysis
48
4.7 Chapter Summary
49
CHAPTER 5 - CASE STUDY
50
5.0 Introduction
50
5.1 HEAnet
50
5.2 NUIG ISS
55
5.3 Chapter Summary
56
PAGE CHAPTER 6 - QUESTIONNAIRE AND INTERVIEW DESIGN
58
6.0 Introduction
58
6.1 PESTEL
58
6.2 SWOT
58
6.3 BCP
59
6.4 Questionnaire Structure
59
6.5 Interview Structure
60
6.6 Chapter Summary
60
CHAPTER 7 - RESULTS AND ANALYSIS
62
7.0 Introduction
62
7.1 Literature Review Analysis
62
7.2 Literature Analysis (Analysis)
62
7.3 Questionnaire Analysis
62
7.4 Case Study Analysis
64
7.5 Summary of Questionnaire Results
64
7.6 Final Result
67
CHAPTER 8 - CONCLUSIONS
68
8.0 Final Conclusion
68
8.1 Results in Context
69
8.2 Identifying Future Work
71
References
72
APPENDICES
76
Appendix A – Questionnaire to Gareth Eason of HEAnet
76
Appendix B – Questionnaire to Tom Regan of NUIG-ISS
84
PAGE Appendix C – Thesis Process Evaluation
89
Appendix D - List of Figures
91
Appendix E - List of Abbreviations
92
Page |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.4x1038 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 doesn’t 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
Page |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.
Page |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
Page |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
Page |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 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
Page |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.
Page |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 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 California’s 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
Page |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
Page |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)
P a g e | 10
A the heart of Ethernett is the Etheernet frame; (Spurgeon, 2000) desccribes the elements At of the Ethernet E fram me as follow ws: (1) The Preamble field f is usedd to synchroonise commuunicating traansceivers, (2) ( the 48 bit Destinatio on and Sourrce address are the Eth hernet addresss of the receeiver and sennder respecttfully, (3) th he Type/Veersion field iis used to in ndicate the form mat of the data d carried in i the paylooad field, (4 4) the actuall Payload Data and finaally (5) the Fram me Check Sequence S is used to carrry the resullt of the FCS S to aid in ddetection off transmiission errorss . Figure 2 shows the latest l implem mentation (Version ( 2) of the Ethernet frame.
F Figure: 2 Thhe Ethernet V2 V frame Source: S (Spuurgeon, 20000) A this stage it is importtant to undeerstand that layer 1 and layer 2 onlly facilitate point to At point coommunicatiion betweenn two netwoork nodes att any one tim me, practicaal situationss demandd that inform mation be inntelligently routed throu ugh many inntermediaryy nodes and d over vast disstances. This situation is i handled by b layer 3, th he Networkk layer. Wheen an Ethern net frame reeaches its destination d t receivingg node extracts the IP packet the p from m the framess payloadd section, thhe IP packett is then passsed up to Layer L 3 the Network N layyer. This is where w IP connnectivity is established. e 3.23 Layer 3 (Networkk) The Networkk layer of thhe OSI model is respon nsible for forrmatting, adddressing an nd P packets. IPv4 uses ann IP addresss size of 32 bits while IIPv6 uses a 128 bit fragmenntation of IP addresss size. (Spurrgeon, 20000) points outt that “...in a given com mputer it is aaware of (its own) 32-bit IP address and a 48-bit Ethernet E adddress. However it doesnn't know thee Ethernet
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 other’s 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 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 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 a g e | 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 a g e | 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 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) 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 MTU’s and their associated technologies as illustrated in figure 6.
P a g e | 16
s comparisons of Layyer 2 techno ologies Souurce: (Parkeer & Siyan, 2002) Figurre 6 MTU size 3.36 IPv4 Fragmentati F ion A IP packetts are sent out As o over the Internet theey will havee to traversee a diverse mixture m of netw works each built b on a vaariety of Layyer 2 techno ologies, therrefore an IP P packet neeeds to be able to be brokeen into smalller parts to overcome different d MTU sizes enncountered in i each networkk. These fraagments thenn need to bee reassemblled in sequeence at the oother end off the link. Thhis process is i handled by b the fragm mentation mechanism m inn IPv4. A summ mary of poinnts are takenn from (Posstel, 1981b) illustrates how h fragmeentation wo orks: W When fragmeentation occcurs, some options o are copied, butt others rem main with thee first frragment onlly. The fieldds which maay be affectted by fragm mentation innclude: Optiions Fiield, More Fragments F F Flag, Fragm ment Offset, Internet Heeader Lengtth Field, To otal Length Fieldd and Headeer Checksum m... The Fraagment Offsset field idenntifies the fragment fr loocation, relaative to the beginning b o the origin of nal un-fragm mented dataggram... Thee innternet identtification fieeld (ID) is used u togetheer with the source and destination adddress, and the protocool fields, to identify i dattagram fragm ments for reeassembly. (pp. 23244) K Keeping in mind m that onnce an IP paacket has beeen fragmennted each fraagment beco omes an indepenndent entity and can be directed seeparately fro om its sisterr fragments over differeent networkk routes; thiis concept iss called dataagram indep pendence ass outlined inn (Postel, 19 981b).
P a g e | 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 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 multicasting…IP 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 a g e | 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
P a g e | 20
o any type (unicast, annycast, and m multicast)… … Linkallso have muultiple IPv6 addresses of Local addressses are desiigned to be used for ad ddressing onn a single linnk for purpo oses suuch as autom matic addreess configuration, neigh hbour discovvery, or whhen no routeers are prresent… Roouters must not forwardd any packeets with Linnk-Local souurce or destiination adddresses to other links… … Link-Loccal addressees have the following fformat (as per p figure 9)… where w the innterface ID is i (usually crafted) c from m the MAC C address off the innterface. (ppp. 5-11)
Figure 9 Link-locaal unicast adddress Sourrce: (Hindenn & Deeringg, 2006)
Figuree 10 Globall unicast adddress Source: (Hinden & Deering,, 2006) The next type of IPv6 adddress is thee global uniicast addresss used for eevery day ro outing 1 The glob bal routing prefix p is a (typically of IPv6 packets and illustratedd in figure 10. hierarchhically-strucctured) valuue assigned to a site (a cluster of suubnets/linkss), the subn net ID is an identtifier of a link within thhe site, and the interfacce ID is usuually craftedd from the MAC M addresss of the interrface as outlined by (H Hinden & Deeering, 20066). 3.43 IPv6 Encapsulati E on and Forrmatting
Figuure 11 IPv6 encapsulation Source: (Deering & Hinden, 11998)
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 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 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 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 Jumbo-grams; these are packets with a payload larger than 65,535 bytes. Jumbo-grams are achieved through
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. 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 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
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) 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 subnetwork 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 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 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 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 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 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 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 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 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 a g e | 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 wouldn’t 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
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 they’re 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 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 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 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 node’s 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 node’s care-ofaddress... 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. 103104) 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 a g e | 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 (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-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 a g e | 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) (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 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 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 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 MN’s COA on the foreign network direct to the CN, where the second method is known as route optimisation.
P a g e | 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 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
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 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 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.,
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 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 dualstacked 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 Réseaux IP Européens (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 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 RIR’s, 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
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, 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 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 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 a g e | 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 testbed 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 a g e | 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 a g e | 47
protocols (AH and ESP) compared to none or one protocol, due to very minimal performance costs. (p. 697) In an evaluation of IPv4/IPv6’s 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 a g e | 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
32
128
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 Jumbo-grams)
20
40
MTU on Ethernet (bytes):
1500
1500
Fragmentation support:
Yes
Yes, (only at source node)
Via ARP
Via NDP
Yes, via IGMP
Yes, via MLD
CIDR support:
Yes
Yes
Mobile IP support:
Yes
Yes
IP address size (bits): IP addresses achievable: IP address format:
IP header size (bytes):
IP address discovery: Multicast support:
Throughput performance:
IPv4 = IPv6
Jitter and packet loss rate:
IPv4 = IPv6
Round trip time: (ms)
IPv6 > IPv4
P a g e | 49
OS dependence:
IPv4 & IPv6 work just as well on newer OS’s 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 a g e | 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 FibreOptic 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 a g e | 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.
P a g e | 52
Figure 21 2 HEAnet National N 10 0Gb/s Fibre Network H HEAnet not only providde National network co onnectivity they t also provide a rang ge of servicess to their cliient base, ass illustratedd in (HEAneet, 2009) theese servicess and their associatted descripttion are shown in table 22.
P a g e | 53
SERVICE: DESCRIPTION
IP CONNECTIVITY: Enables Internet transit at speeds up to 10Gbit/s within Ireland and over connections to the UK and Europe. POINT‐TO‐POINT SERVICES: Enables point-to-point services to serve intra-institute and inter-institute needs. RESILIENT CONNECTIVITY: Enables clients to build resilient connectivity solutions, guaranteeing the highest levels of service availability. CO‐LOCATION: Enables clients to install equipment in a managed data centre facility. WEBSITE HOSTING: Enables website hosting services to interest groups belonging to the Irish higher education and research community WEBSITE HOT STANDBY: Enables clients, fail over protection for their primary web servers. WIKI HOSTING: 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. VIRTUAL LEARNING ENVIRONMENT HOSTING: Enables the management of educational courses, especially by helping teachers and learners with course administration. SOFTWARE MIRRORING: Enables a mirror service to mirror free software and content relevant to the academia. IP ADDRESSES: HEAnet provides IP addresses to its clients in education and research in Ireland. LOOKING GLASS: We host a Looking-Glass which provides a view of the Internet as seen from our routers. MULTICAST IP: Multicast is fully deployed across the HEAnet backbone. Multicast enables
P a g e | 54
efficient delivery of IPTV services across your campus network. NETFLOW: Netflow’s 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. .IE REGISTRATION: HEAnet member institutions may register 2nd 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. MAILING LISTS: Any HEAnet member institution may avail of this service to run electronic discussion lists of relevance to the Irish education and research community. USENET NEWS: Enables a full USENET news service to clients in both IPv6 and IPv4. ANTI‐SPAM: Enables automatic detection of email spam and reporting of spamming sites. SECURITY SCANNING: 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. SERVER CERTIFICATE SERVICE (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. MULTI‐MEDIA VIDEO CONFERENCING: This service is available to all HEAnet clients. VIDEO STREAMING: This service allows clients to broadcast video content to very large numbers of participants over IP networks.
P a g e | 55
VIDEO CONTENT ARCHIVING: 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 Queen’s 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 a g e | 56
SERVICE: DESCRIPTION DATA CENTRE SERVICES: Server Hosting, Virtual Server Service, Data Hosting and Backup. E‐MAIL: Student Mail, Staff Mail, BlackBerry and Mobile Data. ICT STRATEGY CO‐ORDINATION: 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). SERVICE DESK: 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. STAFF DESKTOP SUPPORT (2ND LEVEL DESKTOP SUPPORT): 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. STUDENT DESKTOP: PC Suites (Provisioning/Readiness), Assistive Technology, Student Printing. TEACHING & LEARNING SUPPORT: Blackboard, LEAS - Linux Environment for Academic Studies, Exam services, PC Suite booking, Lecture Theatre PCs. WEB SERVICES: 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 a g e | 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 a g e | 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 (Johnsón, 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 (Johnsón, 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 a g e | 59
choices... (It’s) 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 organization’s 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 HEAnet’s and NUIG’s 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 HEAnet’s
P a g e | 60
and NUIG-ISS’s 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, Tom’s 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 a g e | 61
the data that comprises this thesis will be analysed in the following chapter, Results and Analysis.
P a g e | 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. Jitter 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 a g e | 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 a g e | 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 Are your IPv4 address resources scarce? Do you use NAT? Do you plan to acquire further IPv4 address resources? Is any portion of your network IPv6 ready? What is the period of HEAnet/NUIG‐(ISS) IT upgrade cycle? Do you have a formal budget for IPv6 deployment? Have you incorporated IPv6 deployment in your IT upgrade cycle? What have been the financial hurdles in IPv6 deployment? What will be the financial hurdles to IPv6 deployment?
TOM REGAN
GARETH EASON OF HEANET
OF NUIG‐(ISS)
No
No
No Yes and No
Yes No
Yes
No
5 years
4 years
No
No
Yes
No
Vendor Product Differentiation
Not applicable
Not applicable
Staff training
P a g e | 65
In the context of COST, what would you like to see happen? Should the Government provide financial assistance for IPv4/IPv6 issues and benefits? What is your IT strategy in the context of IPv4 and IPv6? What role does IPv6 play in the alignment of your IT and business strategy? Do you see IPv6 playing a role in your BCP? Is IPv4 address depletion a threat to the alignment between your IT and business strategy? In the context of a PESTEL analysis list factors you deem important when assessing IPv4 and IPv6?
Vendors should stop product differentiation No
IPv6 knowledge dissemination and training Yes
Dual‐stacked network
IPv4 only
Current dual‐stacked network and gear is dual‐stacked
Not applicable
Yes
No
No, problem is dealt with
No, plenty of IPv4 resources
P: US Government support E: No interest from customer or manufacturer S: Make more content available on IPv6 T: Parts of IPv6 are still in testing E: 100% IPv6 maybe more “Green” than dual‐stack L: Many security products don’t support IPv6 In the context of a SWOT analysis S: Secure, Supported of IPv4, can you list factors under W: Lack of addresses each heading that IPv4 brings to O: Easy hire IPv4 experts your business? T: Address Depletion In the context of a SWOT analysis of IPv6, can you list factors under each heading that IPv6 brings to your business?
S: Address Scalability W: Limited support O: More Vendor & content provider support T: IPv6 looks very different from IPv4 We must provide IPv4 and IPv6 connectivity for universities.
Given the Irish government’s 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? Does your IPv4 network use No QoS?
P: US Government support E: Cost of staff training S: Ubiquitous computing T: IPv6 tech‐advantages will be a hard sell to management E: If IPv6 is “Green” could be a selling point L: no comment
S: More familiarity with IPv4 W:NAT uses more power, breaks functionality O: NAT useful for security logging T: Weak security in IPv4 S: More IP addresses W: Staff unfamiliar with IPv6 O: Mobility, more devices, new research T: Low integration with other universities If we can identify aspects of IPv6 that are suited to innovation we may have a selling point, we need IPv6 to get US Government contracts
Yes
P a g e | 66
According to the latest IPv6 specification (RFC‐2460, 1998) QoS in IPv6 is still very much experimental. How do you react to this? 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? From a security perspective how do you safeguard your IPv4 and IPv6 network? 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? Have you talked with your software/hardware vendors to see if they offer IPv6 compatible products? Where do you see IPv4 and IPv6 in the technical future of HEAnet/ NUIG‐(ISS)? In your experience with IPv6 what do you see are its short falls? Are there any other critical factors in the IPv4/IPv6 debate that have not been addressed in this questionnaire? What is your view on mobile IP?
Currently not an issue
Ask CISCO
Only effects managed links with Eircom or BT.
No, 100% Ethernet
Netflow + FSWM
DHCP Snooping, Firewalls & Proxy
Modern hardware will negate this
Hardware upgrade will negate this
Yes, new gear must support IPv6
No
More IPv6 and less IPv4
No change from IPv4 in the medium term
Manufacturer support
Not applicable
IPv4 may become a trade able asset
Training, identify who needs IPv6 training and why is business not requiring IPv6
Mobile Telco’s don’t support IPv6, they should.
No comment
P a g e | 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 a g e | 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 ISP’s that operate in Ireland, would be quite insightful. There may well be many new product development and
P a g e | 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. Ireland’s 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 a g e | 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). GÉANT Europe’s Pan-European Research and Education network also offers IPv6 connectivity and promotes IPv6 adoption among its European NREN co-founders (GÉANT 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 Provider’s 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 a g e | 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 a g e | 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-totelecommunications-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 Jumbograms. (RFC 2675). Retrieved from IETF. Available from http://64.170.98.42/html/rfc2675 Carpenter, B., & Jung, 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 dualstack 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 Jersey: 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 a g e | 73
Driving IPv6 Deployment. (2010). Retrieved June 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 José 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-uplate--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 a g e | 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!!PDFE&type=items Johnson, D. B., Perkins, C. E., & Arkko, J. (2004). Mobility Support in IPv6. Retrieved from IETF. Available from http://www.ietf.org/rfc/rfc3775.txt Johnsón, 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--illustratedinternet-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 a g e | 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 a g e | 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 June, 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-editionPostel, 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 a g e | 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/ipaddressing-and-subnetting--including-ipv6
P a g e | 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 a g e | 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 HEAnet’s 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 HEAnet’s 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 a g e | 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 a g e | 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 don’t see need for IPv6 products so manufacturers don’t 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 a g e | 82
Technological It is difficult to recover R&D cost at the moment due to lack of demand for IPv6 products. ISP’s currently have stable networks and given that IPv6 technology is roughly 10 years old and parts of it are still in testing ISP’s 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 a g e | 83
Weaknesses
Support is limited at the moment; routing equipment doesn’t 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 isn’t. New electronic devices do not support IPv6 as much as they should.
SECTION 4 – INNOVATION Given the Irish government’s 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 a g e | 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 MTU’s 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 couldn’t monitor IPv6 due to a lack of support in our monitoring software for IPv6. Our existing tool set for monitoring IPv4 wasn’t 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 don’t 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 doesn’t really support IPv6. On the new 100Mb/s schools network we use IPv4 and we plan to use
P a g e | 85
IPv6 on this network. Schools network traffic is transported as Point to Point over Ethernet (PPoE) and is aggregated by commercial ISP’s such as Eircom and BT. The schools traffic then lands on an aggregation router in the HEAnet core. Also note that commercial ISP’s 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 a g e | 86
What are your views on mobile IP? Mobile Telco’s in the early days adopted IPv6 for use on their network but now they seem to be sticking with IPv4.
P a g e | 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 a g e | 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 a g e | 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 a g e | 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 government’s 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 a g e | 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 aren’t business requesting IPv6. Can you make a few comments on mobile IP in the context of IPv4/IPv6? No comment
P a g e | 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 January 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 a g e | 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 Master’s 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 a g e | 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 a g e | 95
APPENDIX E - List of Abbreviations AH APNIC ARIN ARP ARPANET ASCII BGP CBR CIDR CN COA CPU CWDM DHCP DNS DSL DWDM EBCDIC ESP FA FCS FDDI FLSM FTP GB/s GHz GUI HA HEAnet HTTP HTTP IANA ICT IETF IGMP IHL IP IPSEC IPv4 IPv6
Authentication Header Asia Pacific Network Information Centre American Registry for Internet Numbers Address Resolution Protocol Advanced Research Project Agency Network American Standard Code for Information Interchange Border Gateway Protocol Constant Bit Rate Classless Inter-domain Routing Correspondent Node Care Of Address Central Processing Unit Coarse Wavelength Division Multiplexing Dynamic Host Configuration Protocol Domain Name System Digital Subscriber Line Dense Wavelength Division Multiplexing Extended Binary Coded Decimal Interchange Code Encapsulating Security Payload Foreign Agent Frame Check Sequence Fibre Distributed Data Interface Fixed Length Subnet Mask File Transfer Protocol Giga Bytes per Second Giga Hertz Graphical User Interface Home Agent Higher Education Authority network Hyper Text Transfer Protocol Hyper Text Transfer Protocol Internet Assigned Numbers Authority Information Communications Technology Internet Engineering Task Force Internet Group Message Protocol Internet Header Length Internet Protocol IP Security Internet Protocol version 4 Internet Protocol version 6
P a g e | 96
ISATAP IT ITU-T Kb MAC MAN MB Mbps MN MPEG MRTG MTU NAPT NAT NDP NREN NTP ISS OSI PPP RA RFC RIPE RTT SSL TCP/IP TEP UDP UDP VLSM VOIP WDM
Intra-Site Automatic Tunnel Addressing Protocol Information Technology International Telecommunications Union- Telecoms Kilo bit Media Access Control Metropolitan Area Network Mega Bytes Mega bits per second Mobile Node Motion Picture Expert Group Multi Router Traffic Grapher Maximum Transmission Unit Network Address Port Translation Network Address Translation Network Discovery Protocol National Research & Education Network Network Time Protocol Information Solutions & Services Open Systems Interconnect Point to Point Protocol Router Advertisement Request For Comment Réseaux IP Européens Round Trip Time Secure Socket Layer Transmission Control Protocol / Internet Protocol Tunnel End Point User Datagram Protocol User Datagram Protocol Variable Length Subnet Mask Voice Over IP Wave Division Multiplexing
