Network Performance Metrics for Transition From

NETWORK PERFORMANCE METRICS FOR TRANSITION FROM

IPv4 TO IPv6 NETWORKS

Samuel Wafula Barasa

A thesis submitted in partial fulfilment for the requirements of the award of degree of

Doctor of Philosophy in Information Technology of Kibabii University

November 2019 DECLARATION

This thesis is my original work prepared with no other than indicated sources support and has not been presented for a degree or any other award.

Signature ……………………………………. Date…………………………………

Samuel W. Barasa

PhD/IT/011/14

CERTIFICATION

The undersigned certify that we have read and hereby recommend for acceptance of

Kibabii University a thesis entitled “Network Performance Metrics for Transition from

IPv4 to IPv6 Networks”.

Signature ……………………………………. Date…………………………………

Prof. Samuel Mbugua, PhD

Department of Information Technology (IT)

Kibabii University

Signature ……………………………………. Date…………………………………

Prof. Simon Karume, PhD

Department of Computing and Informatics

Laikipia University

ii COPYRIGHT

This thesis is copyright materials protected under the Berne Convection, the copyright act

2001 and other international and national enactments in that behalf, on intellectual property. It may not be reproduced by any means in full or in part except for short extracts in fair dealing for research or private study, critical scholarly review or discourse with acknowledgement, with written permission of the Dean School of Graduate Studies on behalf of both the author and Kibabii University.

iii DEDICATION

I dedicate this work to my loving wife Isabella Tabani and my son Macmorris Muyonga.

iv ACKNOWLEDGEMENT

First of all, the glory be to the Almighty God who has made it possible for me to come this far. I wish to thank my supervisors Prof. Samuel Mbuguah and Prof. Simon Karume whose invaluable guidance and supervision has enabled me to successfully complete this study.

Their insights have enlightened me in solving technical problems and improved my skills in academic thinking, presentation, and writing. I extend my gratitude to all the lecturers who imparted the academic knowledge acquired during the proposal and thesis development.

I also wish to extend my gratitude to the Department of Information Technology, the

School of Graduate Studies, and Kibabii University at large for their continuous support towards the Doctor of Philosophy in Information Technology programme.

I would like also to thank my PhD classmates for their moral support, guidance and assistance. I also wish to thank my parents, and siblings whose continuous love, encouragement, moral and material support have made me what I am today. I also wish to recognize the National Commission for Science, Technology and Innovation for funding this study.

v ABSTRACT

The internet platform has been facilitated by a huge number of interconnected network nodes hence the dire need for extra pool of addresses, quality of services, routing efficiency, performance and optimization. These developments have contributed to the implementation of IPv6 to replace and improve the depleted IPv4 address pool. Although IPv6 promises enhancements to IPv4 standards, it’s evident it is maturing albeit slowly despite its implementation on major networks and operating systems. However, IPv6 transition presents performance degradation challenges to the Internet Protocol at implementation. These include bandwidth, throughput, latency and jitter performance with regard to the data, video, and voice traffic. Several solutions have been proposed, including dual-stacking, tunneling, and translation transition strategies that are not yet mature. The study purpose to enhance performance for transition from IPv4 to IPv6 networks to solve the performance degradation problems caused by the premature transition strategies and expedite IPv6 deployment. This study was achieved by establishing the performance degradation associated with transition mechanisms in transiting from IPv4 to IPv6 networks, analyzing how the mapping of configuration attributes to transition mechanisms affect performance degradation from IPv4 to IPv6 networks, and developing a model for smooth transition from IPv4 to IPv6 networks. This was accomplished by experimental design. The target population was on ISPs networks operating in Kenya. Purposive sampling was used to select service providers running on both IPv4 and IPv6 networks. Data collection combined interviews and content analysis. Internal consistency reliability estimation was administered to network experts on one occasion to estimate reliability. Feel for data (descriptive) and goodness of data (inferential) analysis was employed by the study. There were three primary components designed to enhance performance in form of traffic recognition and prioritization application for making decisions in the IPv6 deployments: the IPv6 transition app, the IPv6 transition controller, and the type of service (ToS) database. This study is an enabler for ultra-high performance networks providing for more efficient interconnection between bandwidth intensive Web and information service providers and customers. This will improve government operations for streamlining services for more citizens, improve quality and delivery of services countrywide, increase economic activity and jobs for urban and rural areas and foster high speed universal Internet access.

vi TABLE OF CONTENTS DECLARATION...... ii COPYRIGHT ...... iii DEDICATION...... iv ACKNOWLEDGEMENT ...... v ABSTRACT ...... vi TABLE OF CONTENTS ...... vii LIST OF APPENDICES ...... xi LIST OF TABLES ...... xii LIST OF FIGURES ...... xv LIST OF EQUATIONS ...... xix LIST OF ABBREVIATIONS AND ACRONYMS ...... xx DEFINITION OF TERMS...... xxvii ORGANIZATION OF THE THESIS ...... xxviii CHAPTER ONE: INTRODUCTION ...... 1 1.1 Background Information to the Study ...... 1 1.2 Statement of the Problem ...... 7 1.3 Objectives ...... 11 1.3.1 Overall Objective ...... 11 1.3.2 Specific Objectives ...... 11 1.4 Research Questions ...... 11 1.5 Research Scope ...... 11 1.6 Significance ...... 12 CHAPTER TWO: LITERATURE REVIEW ...... 14 2.1 Introduction ...... 14 2.2 Internet Protocol Version 4 ...... 14 2.2.1 Classless Inter Domain Routing (CIDR) ...... 20 2.2.2 Network Address Translation (NAT) ...... 20 2.2.3 Dynamic Host Control Protocol (DHCP)...... 22 2.2.4 Challenges of the Temporary Approaches ...... 22 2.3 Internet Protocol Version 5 (IPv5) (RFC 1190) ...... 27

vii 2.4 Internet Protocol Version 6 (IPv6) (RFC 2460) ...... 27 2.4.1 IPv6 Features ...... 28 2.4.2 IPv6 Headers ...... 33 2.4.3 IPv6 Address Types ...... 36 2.4.4. Comparison of IPv4 and IPv6 ...... 38 2.5 IPv6 Transition Mechanisms ...... 41 2.5.1 Dual Stack Transition Mechanism ...... 43 2.5.2 Tunneling Transition Mechanism ...... 45 2.5.3 Translation Transition Mechanism ...... 53 2.5.3.1 Stateless IP/ICMP Translation (SIIT) ...... 54 2.5.3.2 Network Address Translation - Protocol Translation (NAT-PT)...... 55 2.5.3.3 Bump in the Stack (BIS) and Bump in the API (BIA) ...... 56 2.5.4 Evaluation of Transition Methods ...... 57 2.6 Technological Advances in IPv6 Implementation ...... 59 2.6.1 Dual-Stack Model ...... 60 2.6.2 Hybrid Model ...... 61 2.6.3 Service Block Model ...... 62 2.7 Performance Metrics ...... 64 2.7.1 Throughput ...... 64 2.7.2 Latency ...... 64 2.7.3 Jitter ...... 65 2.7.4 Packet Loss ...... 65 2.8 Conceptual Framework ...... 66 2.9 Knowledge Gap ...... 67 2.10 Summary ...... 68 CHAPTER THREE: RESEARCH METHODOLOGY ...... 69 3.1 Introduction ...... 69 3.2 Research Design ...... 69 3.3 Research Population ...... 74 3.4 Sampling Technique ...... 74 3.5 Sampling Frame ...... 75

viii 3.6 Data Collection Methods ...... 76 3.6.1 Content Analysis ...... 76 3.6.2 Interviews ...... 78 3.7 Quality Control of Research Instruments ...... 79 3.7.1 Reliability ...... 79 3.7.2 Validity ...... 80 3.7.2.1 Surveys ...... 80 3.7.2.2 Data Collection Instrument ...... 81 3.7.2.3 Data Collection Approach ...... 82 3.7.2.4 Interpretation of Results ...... 83 3.8 Data Analysis ...... 83 3.9 Model Development ...... 85 3.9.1 Model Design and Development ...... 86 3.9.2 Model Testing and Validation ...... 86 3.10 Ethical Issues ...... 87 3.11 Summary ...... 87 CHAPTER FOUR: MODELLING AND SIMULATION RESULTS ...... 89 4.1 Introduction ...... 89 4.2 Transition Mechanisms for Transiting from IPv4: Content Analysis and Interview Results ...... 90 4.2.1 Content Analysis Results ...... 90 4.2.2 Interview Results ...... 107 4.3 Map of the various configuration attributes from IPv4 to IPv6 Networks: Modeling Designs in OPNET Modeler ...... 110 4.3.1 Modeling Design of Dual Stack IPv6 Transition ...... 116 4.3.2 Modeling Design of IP Tunneling IPv6 Transition ...... 123 4.3.3 Modeling Design of Network Address Translation IPv6 Transition ...... 132 4.4 Model for Transition from IPv4 to IPv6 Networks: Simulations Results and Analysis ...... 137 4.4.1 Simulation Results’ Analysis of Dual Stack IPv6 Transition ...... 138 4.4.2 Simulation Results’ Analysis of IP Tunneling Design of IPv6 Transition ...... 145

ix 4.4.3 Simulation Results’ Analysis of Network Address Translation IPv6 Transition150 4.5 Discussion ...... 154 4.6 Conclusion ...... 156 4.7 Summary ...... 157 CHAPTER FIVE: MODEL DEVELOPMENT ...... 164 5.1 Introduction ...... 164 5.2 Overall Design and Analysis of an Original Application for IPv6 Transition ...... 164 5.3 Simulation Results’ Analysis of the Original Application for IPv6 Transition .... 179 5.3.1 IPv6 Transition Controller Application Operations Simulation Results’ Analysis ...... 180 5.3.2 Simulation Results’ Analysis related to comparison of operations of the IPv6 Transition Controller Application with the previous three IPv6 Transition Designs . 188 ,5.4 Critical Analysis ...... 198 5.5 Summary ...... 200 CHAPTER SIX: VALIDATION OF THE MODEL ...... 201 6.1 Introduction ...... 201 6.2 Presentation of Survey Data ...... 204 6.3 Analysis of Survey Data and Discussions ...... 213 6.4 Summary ...... 217 CHAPTER SEVEN: RECOMMENDATIONS, FUTURE WORK & CONCLUSION ...... 219 7.1 Summary of the Research ...... 219 7.2 Conclusions ...... 223 7.3 Generalizations ...... 225 7.4 Recommendations for Further Research ...... 227 REFERENCES ...... 228 APPENDICES ...... 240

x LIST OF APPENDICES

Appendix A: List of RFCs ...... 240 Appendix B: Content Analysis Schedule ...... 247

Appendix C: Interview Schedule ...... 248

Appendix D: Structured Questionnaire as the Survey Instrument ...... 249

Appendix E: Multiple Regression Output Tables ...... 256

Appendix F: MANOVA Output Tables ...... 259

Appendix G: Series of ITU-T Recommendations ...... 263

Appendix H: Publications ...... 265

Appendix I: Research Authorization Permit ...... 266

Appendix J: Research Permit ...... 267

Appendix K: Research Grant Letter ...... 268

xi LIST OF TABLES

Table 2. 1: The addressing scheme ...... 16 Table 2. 2: IPv6 address type ...... 37 Table 2. 3: Comparison of IPv4 and IPv6...... 39 Table 2. 4: Comparison of transition methods ...... 58 Table 3. 1: Comparison of popular network simulators ...... 73 Table 4. 1: Summary of collected data from content analysis for RFCs ...... 91 Table 4. 2: Electronic databases used in the search process ...... 94 Table 4. 3: Details of research studies, research context and methodology, and findings on performance comparisons of IPv6 transition schemes ...... 94 Table 4. 4: Details of research studies, research context and methodology, and findings on performance tunneling transition scheme ...... 103 Table 4. 5: Summary of collected data from content analysis and interview from ISPs 108 Table 4. 6: IP address assignments in the dual stack implementation ...... 121 Table 4. 7: IP address assignments in the IP tunneling implementation ...... 124 Table 4. 8: IP address assignments in the network address translation implementation 132 Table 4. 9: The performance parameters summary for dual stack transition scheme after the end of 180 seconds simulation time ...... 145 Table 4. 10: The performance parameters comparison summary for dual stack and 6to4 tunneling transition schemes after the end of 180 seconds simulation time ...... 150 Table 4. 11: The performance parameters comparison summary for dual stack, 6to4 tunneling, and Network Address Translation transition schemes after the end of 180s simulation time...... 157 Table 5. 1: IP address assignments in the original IPv6 transition controller application implementation of IPv6 transition ...... 166 Table 5. 2: The performance parameters comparison summary statistics against simulation time for dual stack, 6to4 tunneling, Network Address Translation transition schemes, and IPv6 transition controller application ...... 191 Table 6. 1: Frequency and percentages of the location of experience of the respondents ...... 204

xii Table 6. 2: Frequency and percentages of the number of years of experience in TCP/IP networking ...... 205 Table 6. 3: Descriptive statistics for the number of years of experience in TCP/IP networking ...... 206 Table 6. 4: Multiple regression model summary for the construct with and without moderators for dependent variable as bandwidth performance (BANDP) ...... 206 Table 6. 5: ANOVA table of the construct with and without moderators for dependent variable as bandwidth performance (BANDP) ...... 207 Table 6. 6: Multiple regression model summary for the construct with and without moderators for dependent variable as throughput performance (THRP)...... 209 Table 6. 7: ANOVA table of the construct with and without moderators for Dependent Variable as Throughput performance (THRP) ...... 209 Table 6. 8: Multiple Regression Model Summary for the construct with and without moderators for Dependent Variable as Latency performance (LATP) ...... 210 Table 6. 9: ANOVA table of the construct with and without moderators for dependent variable as latency performance (LATP) ...... 211 Table 6. 10: Multiple regression model summary for the construct with and without moderators for dependent variable as jitter performance (JITTP) ...... 212 Table 6. 11: ANOVA Table of the construct with and without moderators for dependent variable as jitter performance (JITTP) ...... 212 Table 6. 12: Descriptive statistics for the independent variables, the moderators, and the dependent variables ...... 213 Table B. 1: Content analysis schedule ...... 247 Table E. 1: Multiple Regression Statistical Significance Table with and without moderators for Dependent Variable as bandwidth performance (BANDP) ...... 256 Table E. 2: Multiple Regression Statistical Significance Table with and without moderators for Dependent Variable as throughput performance (THRP) ...... 256 Table E. 3: Multiple Regression Statistical Significance Table with and without moderators for Dependent Variable as latency performance (LATP) ...... 257 Table E. 4: Multiple Regression Statistical Significance Table with and without moderators for Dependent Variable as jitter performance (JITTP) ...... 258

xiii Table F. 1: MANOVA Table of independent and dependent variables without moderators ...... 259 Table F. 2: MANOVA Table of independent and dependent variables with moderators ...... 260

xiv LIST OF FIGURES

Figure 1. 1: Some network protocols at each layer ...... 5 Figure 2. 1: IPv4 classes ...... 15 Figure 2. 2: Internet users in the World ...... 17 Figure 2. 3: Percentage of users that access Google over IPv6 ...... 18 Figure 2. 4: IPv6 adoption around the world ...... 19 Figure 2. 5: IPv6 adoption in Africa ...... 19 Figure 2. 6: Network address translation ...... 21 Figure 2. 7: IPv6 addressing ...... 28 Figure 2. 8: The comparison of IPv4 and IPv6 header ...... 34 Figure 2. 9:Transition strategies ...... 42 Figure 2. 10: Dual stack architecture ...... 44 Figure 2. 11: Tunneling...... 45 Figure 2. 12: Generic Routing Encapsulation - IPv4 tunnel ...... 47 Figure 2. 13: Components of Intra-Site Automatic Tunnel Addressing Protocol tunneling infrastructure ...... 48 Figure 2. 14: Components of 6to4 tunneling ...... 49 Figure 2. 15: 6to4 network implementation diagram...... 50 Figure 2. 16: Components of Teredo tunneling ...... 52 Figure 2. 17: Components of tunnel broker tunneling infrastructure ...... 53 Figure 2. 18: Network Address Translation - Protocol Translation...... 55 Figure 2. 19: Bump in the Stack (BIS) ...... 57 Figure 2. 20: Comparison of transition methods ...... 59 Figure 2. 21: Dual stack model ...... 60 Figure 2. 22: Hybrid model example ...... 62 Figure 2. 23: Service block model implementation example ...... 63 Figure 2. 24: Conceptual framework ...... 66 Figure 3. 2: Research methodology ...... 79 Figure 4. 1: Simulation methodology ...... 111 Figure 4. 2: The design of the model for IPv6 transition ...... 112 Figure 4. 3: IP compression schemes ...... 113

xv Figure 4. 4: Application traffic configurations for the three IPv6 transition designs ..... 114 Figure 4. 5: Application runtime profile configurations for the three IPv6 transition designs...... 115 Figure 4. 6: Servers IP addressing showing IPv4 (only) assignment for dual stack ...... 117 Figure 4. 7: Client LANs IP addressing showing IPv6 (Only) assignment for dual stack ...... 118 Figure 4. 8: Switches IP addressing showing IPv4 assignment for dual stack ...... 119 Figure 4. 9: Switches IP addressing showing IPv6 assignment for dual stack ...... 120 Figure 4. 10: Tunnel interface configuration on switch SW_1 ...... 127 Figure 4. 11: Tunnel interface configuration on switch SW_3 ...... 127 Figure 4. 12: Tunnel interface configuration on switch SW_4 ...... 128 Figure 4. 13: Tunnel configuration on switch SW_1 ...... 129 Figure 4. 14: Tunnel configuration on switch SW_3 ...... 130 Figure 4. 15: First tunnel configuration on switch SW_4 ...... 131 Figure 4. 16: Second tunnel configuration on switch SW_4 ...... 131 Figure 4. 17: NAT configuration-1 on switch SW_4 ...... 135 Figure 4. 18: NAT configuration-2 on switch SW_4 ...... 136 Figure 4. 19: NAT configuration-3 on switch SW_4 ...... 137 Figure 4. 20: IPv6 and TCP performance of dual stack model ...... 139 Figure 4. 21: Database query performance and traffic of dual stack ...... 140 Figure 4. 22: Video conferencing performance and traffic of dual stack model ...... 141 Figure 4. 23: Voice application performance and traffic of dual stack ...... 144 Figure 4. 24: IPv6 and TCP performance of IP tunneling model ...... 146 Figure 4. 25: Database query performance and traffic of IP tunneling model ...... 147 Figure 4. 26: Video conferencing performance and traffic of IP tunneling model ...... 148 Figure 4. 27: Voice application performance and traffic of IP tunneling model ...... 149 Figure 4. 28: IPv6 and TCP performance of IP-NAT model ...... 151 Figure 4. 29: Database query performance and traffic of IP NAT model ...... 152 Figure 4. 30: Video conferencing performance and traffic of IP-NAT model ...... 153 Figure 4. 31: Voice application performance and traffic of IP NAT model ...... 154

xvi Figure 5. 1: Network reorganization for running the original IPv6 transition controller application design created in this study for IPv6 transition ...... 165 Figure 5. 2: Three workflows of the original IPv6 transition controller application, each with four transactions in request-response mode ...... 170 Figure 5. 3: Destination settings for responses of IPv6 transition controller for DB destination query ...... 171 Figure 5. 4: Destination settings for responses of IPv6 transition controller for video destination query ...... 172 Figure 5. 5: Destination settings for responses of IPv6 transition controller for type of service (ToS) DB ...... 173 Figure 5. 6: Relational ToS DB records entries: relating the maximum queue sizes, priority labels, and services categories ...... 174 Figure 5. 7: Relational ToS DB records entries: relating the byte counts, maximum queue sizes, and services categories ...... 175 Figure 5. 8: Relational ToS DB records entries: relating the reservation policies with bandwidth and buffer sizes ...... 176 Figure 5. 9: Relational ToS DB records entries: relating the traffic policy with average rate, normal burst size, excess burst size ...... 177 Figure 5. 10: Defining IPv6 transition controller as a custom application and ToS DB as a medium load database; these are essential for simulations ...... 178 Figure 5. 11: Defining runtime settings for IPv6 transition controller; these are essential for simulations ...... 179 Figure 5. 12: Packet network delay, response times, and overall traffic of each of the three phases of IPv6 transition controller application executed for traffic recognition and routing of data, video, and voice traffic ...... 181 Figure 5. 13: Response times and traffic of initial application demands raised by two of the Client LANs to the IPv6 transition controller application executed for requesting for traffic recognition and routing of data, video, and voice traffic ...... 182 Figure 5. 14: Request-Response round trip times of each of the three phases of IPv6 transition controller application executed for traffic recognition and routing of data, video, and voice traffic ...... 183

xvii Figure 5. 15: Request and response packet network delays of each of the three phases of IPv6 transition controller application executed for traffic recognition and routing of data, video, and voice traffic ...... 184 Figure 5. 16: Overall requests and response traffic to/from the IPv6 transition controller application executed for traffic recognition and routing of data, video, and voice traffic ...... 185 Figure 5. 17: Overall sizes and load of all requests sent to the IPv6 transition controller application for traffic recognition and routing of data, video, and voice traffic ...... 187 Figure 5. 18: TCP performance after completing the three phases of IPv6 transition controller application ...... 188 Figure 5. 19: Database performance after completing the three phases of IPv6 transition controller application ...... 189 Figure 5. 20: Video performance after completing the three phases of IPv6 transition controller application ...... 190 Figure 5. 21: Voice performance after completing the three phases of IPv6 transition controller application ...... 191 Figure 6. 1: Encoding of variables and defining their levels in SPSS ...... 201 Figure 6. 2: Value labels set in SPSS for country of a respondent ...... 202 Figure 6. 3: Value labels set in SPSS for number of years of experience of the respondents ...... 202 Figure 6. 4: Value labels set in SPSS for the independent variables and the moderators ...... 203 Figure 6. 5: Value labels set in SPSS for the dependent variables ...... 203 Figure D. 1: The conceptual model...... 249 Figure D. 2: The developed model ...... 250 Figure I. 1: Research Authorization Permit ...... 266 Figure J. 1: Research Permit ...... 267 Figure K. 1: Research Grant Letter ...... 268

xviii LIST OF EQUATIONS

Equation 2. 1 ...... 64 Equation 2. 2 ...... 65

Equation 2. 3 ...... 65

Equation 2. 4 ...... 66

xix LIST OF ABBREVIATIONS AND ACRONYMS

3D : Three Dimensional 3G : Third Generation 3GPP : Third Generation Partnership Project AAAA : Authentication, Authorization, and Accounting ACM : Association for Computing Machinery ACR : Absolute Category Rating ADDP : Addressing Plan AFRINIC : African Network Information Centre AH : Authentication Header AIM : AOL Instant Messenger ALG : Application Layer Gateway ANOVA : Analysis of Variance AOL : American Online API : Application programming Interface APNIC : Asia-Pacific Network Information Centre ARIN : American Registry for Internet Numbers ARP : Address Resolution Protocol ARPA : Advanced Research Projects Agency ARPANET : Advanced Research Projects Agency Network AS : Access Stratum ATM : Asynchronous Transfer Mode AVC : Advanced Video Coding BANDP : Bandwidth Performance BIA : Bump in the Application programming Interface BIS : Bump in the Stack BGP : Border Gateway Protocol CAK : Communication Authority of Kenya CERNET : China Education and Research Network CIDR : Classless Inter-Domain Routing CIFS : Common Internet File System

xx CPU : Central Processing Unit CQI : Channel Quality Indicator CRTP : Compressed Real-Time Protocol DB : Database DHCP : Dynamic Host Configuration Protocol DHCPv6 : Dynamic Host Configuration Protocol version 6 DOD : Department of Defense DNS : Domain Name System DSLite : Dual-Stack Lite DSM : Dual-Stack Model DSTM : Dual Stack Transition Mechanism EMM : EPS Mobility Management EPC : Evolve Packet Core EPS : Evolved Packet System ESM : EPS Session Management ESP : Encapsulating Security Payload FDD : Frequency Division Duplex FDDI : Fiber Distributed Data Interface FIFO : First In First Out FTP : File Transfer Protocol GloMoSim : Global Mobile Information System Simulator GPRS : General Packet Radio Services GRE : Generic Routing Encapsulation GTNetS : Georgia Tech Network Simulator GTP : GPRS Tunneling Protocol GUI : Graphical User Interface HARDC : Hardware Compatibility HARQ : Hybrid Automatic Repeat Request HTTP : Hypertext Transfer Protocol IANA : Internet Assigned Number Authority IBM : International Business Machine

xxi ICMP : Internet Control Message Protocol ICMPv6 : Internet Control Message Protocol version 6 ICT : Information and Communication Technology ID : Identity IDE : Integrated Desktop Environment IEEE : Institute of Electrical and Electronic Engineers IEN : Internet Engineering Note IETF : Internet Engineering Task Force IF : Interface IMPLC : Implementation Cost IP : Internet Protocol IPng : Internet Protocol next generation IP NAT : Internet Protocol Network Address Translation IPSec : Internet Protocol Security IPv4 : Internet Protocol version 4 IPv5 : Internet Protocol version 5 IPv6 : Internet Protocol version 6 IPv6NET : Internet Protocol version 6 NETwork ISATAP : Intra-Site Automatic Tunnel Addressing Protocol ISO : International Organization for Standardization ISOC : Internet Society ISP : Internet Service Provider IT : Information Technology ITU : International Telecommunication Union JITTP : Jitter Performance KB : Kilo Bytes KBPS : Kilo Bytes Per Second LACNIC : Latin America and Caribbean Network Information Centre LAN : Local Area Network LATP : Latency Performance LIFO : Last In First Out

xxii LOADB : Load Balancing LTE : Long-Term Evolution MAC : Media Access Control MANOVA : Multivariate Analysis of Variance MBMS : Multimedia Broadcast Multicast Services MBPS : Megabits Per Second MIPv6 : Mobile IP version 6 MME : Mobility Management Entity MOS : Mean Opinion Score MOS-LQO : Mean Opinion Score - Listening Quality Objective MP4 : Moving Pictures Experts Group 4 Advanced Video Coding

MPEG : Moving Pictures Experts Group MPLS : Multiprotocol Label Switching MRIP : Multiple Replications in Parallel MTU : Maximum Transmission Unit NAS : Non-Access Stratum NAT : Network Address Translation NAT64 : Network Address Translation 64 NAT-PT : Network Address Translation – Protocol Translation ND : Neighbour Discovery NED : NEtwork Description NetSim : NETwork SIMulation NETWC : Network Convergence NFS : Network File System NS2 : Network Simulator 2 OS : Operating System OSI : Open Systems Interconnection OMNET : Objective Modular Network Testbed OMNET++ : Objective Modular Network Testbed in C++ OPNET : Optimized Network Engineering Tool OSPF : Open Shortest Path First

xxiii OSPFv3 : Open Shortest Path First version 3 P2P : Point to Point protocol PAT : Port Address Translation PC : Personal Computer PDCP : Packet Data Convergence Protocol PDM : Performance and Diagnostic Metrics PDN : Public Data Network PESQ : Perceptual Evaluation of Speech Quality PHY : Physical PHYC : Physical Connectivity PING : Packet Inter-Network Groper PRL : Potential Router List PSQM : Perceptual Speech Quality Measure QoS : Quality of Service RAM : Random Access Memory RARP : Reverse Address Resolution Protocol RFC : Request for Comments RIP : Routing Information Protocol RIPE : Réseaux IP Européens RIR : Regional Internet Registries RLC : Radio Link Control RMON : Remote Network Monitoring RNG : Random Number Generator ROUTP : Routing Plan RPC : Remote Procedure Call RQ : Research Question RTT : Round Trip Time SBM : Service Block Model SD : Standard Deviation SERVP : Service Plan SGW : Serving Gateway

xxiv SIIT : Stateless Internet Protocol/ Internet Control Message Protocol Translation SIP : Session Initiation Protocol SLAAC : Systems Level Applications of Adaptive Computing SMTP : Simple Mail Transfer Protocol SNMP : Simple Network Management Protocol SP1 : Service Pack One SP2 : Service Pack Two SPSS : Statistical Package for Social Sciences ST : Internet Stream Protocol ST2 : Internet Stream Protocol 2 ST2++ : Internet Stream Protocol 2 Plus Plus SVR : Server SW : Switch TCP : Transmission Control Protocol TCP/IP : Transmission Control Protocol/Internet Protocol TDD : Time Division Duplex TECHE : Technical Expertise TELNET : TELecommunications NETwork TFTP : Trivial File Transfer Protocol THRP : Throughput Performance TMN : Telecommunications Management Network TRANS : Transition Mechanism ToS : Type of Service ToS DB : Type of Service Database TSP : Tunnel Setup Protocol TTL : Time to Live TV : Television UDP : User Datagram Protocol UMTS : Universal Mobile Telecommunications System UE : User Equipment

xxv URL : Universal Resource Locator US : United States VINT : Virtual InterNetwork Testbed VLAN : Virtual Local Area Network VoIP : Voice over Internet Protocol VPN : Virtual Private Network VVIPs : Very Very Important Persons WAN : Wide Area Network Wi-Fi : Wireless Fidelity WiMAX : Worldwide Interoperability for Microwave Access WLAN : Wireless Local Area Network WWW : World Wide Web XDR : External Data Representation

xxvi DEFINITION OF TERMS

Internet Protocol

The Internet Protocol is a protocol that operates at the network layer or layer three (3) of the OSI model and the internet layer of the TCP/IP protocol suite. It is a protocol responsible for LAN and WAN communications for inbound and outbound traffic to the internet.

Internet Protocol Version 4

IPv4 protocol is a 32-bit address system for Ethernet communication that contains address and control information. The essence of this information is to enable packets to be routed in a network.

Internet Protocol Version 6

IPv6 protocol is a 128-bit address system. It has been referred to as the next generation internet protocol developed to expand the pool of addresses to cater for the increased need of connectivity of smart devices to the internet. This version is an upgrade of IPv4 that was developed by IETF mainly to address the depleted IPv4 address space.

xxvii ORGANIZATION OF THE THESIS

The thesis constitutes of seven chapters for both theoretical and empirical portions of study findings. Chapter one covers the introductory aspects of the thesis and it widely covers the theoretical aspects, that describes the background, objectives, goal, scope and the contributions of the thesis. Besides, the study combines both the theoretical and practical aspects through change reflected in a complex scenario. This is a task comprising of researchers, experts, and practitioners committed to work together on a range of tasks, including problem discovery, achievement arbitration, and learning.

Chapter two is the literature review. It comprehensively highlights the state of the art and practice of both Internet Protocol version 4 and version 6 in the study. These includes the detailed technological advancements in the field of networking, models, tools, optimization techniques, and methods. The critique of the literature and gaps in the literature worth research are identified.

Chapter three is the research methodology. It deals mainly with research strategy, methods and data collection framework in line with the research questions and objectives, research strategy, scope, validity and reliability of research instruments, data collection and analysis.

Chapter four is the modelling and simulation of findings. This contains information about modelling design and simulation of the Internet Protocol transition mechanisms, Dual

Stack, Tunneling and Network Address Translation (NAT). It details the empirical portion performed on a simulated ISP core network monitoring and analysis to deduce the contemporary operating core network infrastructure statistics.

xxviii Chapter five is the proposed model development. It comprises the presentation of the original transition application. It also highlights the overall analysis, design and simulation results’ analysis of the original application for IPv6 transition.

Chapter six is the validation of the model by networking experts. The findings of the validation process are presented based on the survey data from technocrats. The reliability, validity, and conformability of the final design is tested with the help of statistical evaluation.

Chapter seven is recommendations, future work and conclusion. It includes a review of the thesis, technological innovations, unconventionality and model constraints, including the analysis of findings upon implementation. It presents the general conclusions, generalizations, and proposes directions of the study that can be investigated by researchers and practitioners as future work.

xxix CHAPTER ONE

INTRODUCTION

1.1 Background Information to the Study

The internet is the interconnection of computer networks with several connection of nodes globally. The nodes may include desktops, laptops, palmtops, tablets, smart devices, or any electronic device that support ethernet communication standard (Shelly & Vermaat, 2012;

Ahmed, Mustafa, & Ibrahim, 2015). The historical background of the internet dates back in the early 1960’s in the military by the US Department of Defense (DOD) undertaking research projects on packet-switched network systems. This project was dubbed the

Advanced Research Projects Agency Network (ARPANET) whose mandate saw a major implementation of very first network with Internet Protocol. As a result, Internet Protocol was inevitable for sharing of resources.

The TCP/IP protocol suite was proposed in 1974 by founding pioneer‘s of the Internet,

Vinton Cerf and Robert Kahn in a published research article (Shah, 2015; Cerf & Icahn,

2005). From the onset in the mid-1990s, research on networks and Internet has had an unprecedented impact on the operational excellence of all sectors globally. Several technological advancements had taken shape with positive impact on culture, commerce, education, and communication. These includes electronic mailing, instant messaging,

Voice over Internet Protocol (VoIP), video conferencing, internet message board, online weblogs, social network interactions, and electronic commerce stores (Shah, 2015). The

Internet Protocol layer of abstraction is tasked for the transmission of data units between two entities i.e. the sender and receiver. For this task to be accomplished, the sender and receivers’ IP addresses must be established by a unique fixed length addresses (Ahmed,

1 Mustafa, & Ibrahim, 2015). The existence of smart devices, high speed wireless, broadband networks, and rapid explosion of the internet have immensely advanced towards the depletion of version 4 platform.

The IPv4 architecture used in the last three decades accommodates approximately 4 billion addresses assignable to nodes. The assignable addresses are limited since they cannot accommodate the requirements of the current Internet architecture, with the depletion of the address pool challenge (Shah & Parvez, 2014). As a result, some short-term measures were inevitable for continuous connectivity to the Internet. These included Network

Address Translator (NAT) and Classless Inter Domain Routing (CIDR) measures.

Nevertheless, researchers had begun some work on the design of a new Internet Protocol architecture, termed version 6 with some authors dubbed it next generation protocol to replace version 4. The key purpose for the design and implementation of this architecture parallel to the contemporary version was fundamentally to amplify the pool of discrete addresses.

Furthermore, initial types of traffic and protocol applications in existence on the prior

Internet architecture were electronic mails, file transfer and telnet (to login remotely). The existence of these protocols was considered lightweight and accommodative regardless of the network transmission impairments among other network conditions. For the modern architecture, the real time type of protocols and applications needs an advanced degree of guaranteed network efficiency and effectiveness for sustainable delivery of packets on all platforms. The IPv6 platform was designed to effectively and efficiently support all types of traffic, that is, conventional and real time. Additionally, the next generation protocol supported network growth, expandability, protection against access, and packetized

2 multimedia transmissions. To begin with, the amplification of the pool of discrete addresses from 32 bits to 128 bits considered adequate to uniquely assign and support every single entity globally (Shah, 2015). The IPv6 platform accommodates 340 trillion, trillion, trillion addresses assignable to network devices while IPv4 on the other hand has the potential to accommodate approximately 4.3 billion addresses assignable to network devices (Albkerat & Issac, 2014). The IPSec protocol consideration for IPv6 implementation was made mandatory, since it was encapsulated by default in the header.

The Quality of Service (QoS) carried out by routing device is taken care of by the Flow

Label and Traffic class field in the IPv6 packet header. The IP packet fragmentation effect is however implemented solely on the source network devices. The IPv6 packet header eliminates checksum, with no options appended in the packet header, but instigates several extension headers instead. Conclusively, with the new protocol there is absolutely no manual configuration required or DHCP, making it vital considering the amplified number of network devices. It is therefore important to note that, IPv6 platform was perfectly designed with most of the future enhancements into consideration.

The first cohort of Internet users that would be affected by the depleted pool of address space are internet service providers (ISPs). The justification is that ISPs carry the greatest unit of IPv4 addresses for execution and control of domain name services. In the event the

IPv4 addresses runs out, then it will be deemed fit to salvage the exhaustion, else the disintegration of the global computer network is predictable in future (Huston, 2008).

The global computer networks at the larger extent are designed and implemented based on the principle of the OSI framework. This model was formally initiated in 1984 by a group of researchers working under the International Organization for Standardization (ISO), a

3 body responsible for global communication and broken into seven abstract layers for networking. It is a vital component for internet standards derivative. It describes the avenue through which data units at every layer should be exchanged between the source component and the destination component of the network architecture. The fundamental aim of this model is to facilitate communication established between different system platforms (hardware and software) running under different implemented architectural structures for compatibility. Subsequently, the network layers consist of several network protocols and applications running throughout the model. The Internet Protocol operate at layer 3 (network layer) protocol defined and documented in RFC 791 (Postel, 1981) of

IETF. The sole responsibility dedicated by this abstract layer fundamentally delivered network data units as it traverses the communicating entities on the network. For this task to be accomplished, the sender and receivers’ IP addresses must be globally established using a unique address (Ahmed, Mustafa, & Ibrahim, 2015). Figure 1.1 demonstrates protocols traversing Application, Presentation, Session, Transport, Network, Data Link, and Physical layers of the OSI model.

Figure 1. 1: Some network protocols at each layer (Source: Ford, Lew, Spanier, & Stevenson, 1999)

Due to the expeditious, steady internet evolution, the clamor for extra addresses increased exponentially. Nonetheless, the large number of applications and network nodes has depleted the 4 billion pool of addresses routable to the internet and introduced configuration complexities. The highlighted limitations for internet infrastructure, lead to

IETF to realize the dire need to develop a new generation convention in the early 1990s to succeed IPv4 together with new features and the rendered services.

The new generation convention was designed to supplement version 4 depleted range of addresses and amplify performance of the network infrastructure. Additionally, the protocol grants visible solution to the troubles encountered by the fourth-generation protocol. The expanded pool of address space unravels the lack of IP addresses problem, identified as a primary point of interest towards tremendous internet growth (Dutta, 2012).

Better security experience is guaranteed by implementing a mandatory IPSec and flexible

5 extension header option. There are many other considerable benefits including multicasting support, simple header, auto-configuration, and quality of service. The main features that intent to achieve the implementation requirements are enumerated as simple IP header, better addressing scheme, large datagram transfers, and fragmentation elimination for layer

3 devices (Dhole, 2012).

Having explored the features and benefits of the new generation protocol, it is also prudent to highlight some of the challenges incurred upon implementation. There exist a couple of considerable challenges in the available transition strategies, including switching, logical addressing, expandability, network performance as well as state maintenance. The strategies for transition from IPv4 to IPv6 coexistence are diverse and there is no single remedy fit to meet all the much anticipated requirements.

It is evident that the transition challenge has become critical and feasible impediment affecting the deployment of the next platform of the internet (Peng, 2011). The main obstacle has been pointed by researchers on the best approach to transit to version 6 with respective transition problems and implementation difficulties could have prospectively dangerous outcomes incase the state is not satisfactorily addressed. Several challenges are experienced during the transition period if both IPv4 and IPv6 platforms coexist on the same backbone infrastructure.

The core mandate of the development of IPv6 ideally has been to substitute and supplement

IPv4 power as a salient principle of the present-day internet platform. Its birth is the desirable option to IPv4 since it can sustain the increased growth of applications and devices supporting the internet as well as unlock the security concerns posed by IPv4.

Moreover, the deficiency and depletion of IPv4 pool of addresses and the dire requisite

6 towards a strengthened generation of IP that is essentially dependable and secure. These are the reasons why IPv6 deployment has become urgent with emphasis on secure, larger address space, and better performance (Ali, 2013).

It is also evident that IPv6 network platform is maturing, albeit slowly despite the fact that it has been enforced on major networks and most operating systems (Repas, 2014). Most of the core Internet transit providers have utilized the platforms provided and deployed

IPv6. However, the edge networks are lagging in the implementation (Amogh, 2012). Its implementation gave birth to challenges such as depletion of IPv4 address space, configuration intricacy, performance degradation and network operational excellence concerns at the protocol level to be addressed (ISOC, 2014).

Research has been carried out with regard to protocol design, connectivity and routing, and transition to IPv6. Methods have been recommended to evaluate performance degradation and platforms whose focal point is on hardware and IPv6 compatibility. Yagoub (2014), asserts a network whose key role is the provision of public services, its performance is a major concern and with IPv6 it is extremely complicated. The focal point of this study is about the peculiarities of IPv6 from a transition perspective and its performance differences compared to IPv4. The current state of IPv6 usage, IPv4 to IPv6 transition strategies/mechanisms, routing and optimization/performance perspective of this new protocol is the concern (Ali, 2013).

1.2 Statement of the Problem

Rapid internet technology revolution has resulted to exponential increase in network node over time. This scenario has further resulted to depletion of address space on the internet

7 (Chauhan, 2014). Huston (2015) report highlighted four Regional Internet Registries

(RIRs) who registered the last phase of IPv4 Exhaustion. These include NCC, RIPE,

LACNIC and ARIN. AFRINIC is the only RIR operating with a reasonable pool of IPv4 address space. The next generation IPv6 protocol was inaugurated in 1998, but its global rate of deployment is still low, a paltry 3% index (APNIC, 2015). It is pointed out the main reason has been due to lack of compatibility from IPv4 to IPv6 platform. As a result, the

IETF made substantial attempts to put in place the formal transition process by inaugurating exceptional transition schemes as well as offering many other transition strategies to support the process.

Several studies have indicated that all IPv6 transition strategies have merits and demerits on implementation. Ge, Mi, & Wu (2014), confirms there is absence of a universal acceptable transition mechanism fit for all the implementation scenarios. As a result, different IPv6 transition mechanisms may be applicable to different implementation scenarios. This has been a great challenge to heterogeneous networks running both IPv4 and IPv6.

A benchmarking methodology linked to the IPv6 Network Evaluation Testbed (IPv6NET) was proposed by carrying out an experiment devoted to the practicality requirement of quantifying IPv6 transition strategies in a sequence of network monitoring tests

(Georgescu, Hazeyama, Kadobayashi, & Yamaguchi, 2014). However, the scalability factor was not considered. An attempt was made to further work this methodology by suggesting an extra approach to quantify scalability of IPv6 networks (Georgescu,

Hazeyama, Okuda, Kadobayashi, & Yamaguchi, 2015). The methodology points out that developing an IPv4/IPv6 network transition plan requires load scalability to be put into

8 consideration by network operators for dynamism. The load scalability of IPv4/IPv6 transition strategies affect both small and bigger networks from the performance degradation analysis perspective. This approach lacks empirical data, since there is no open source system platform available to provide a comparative analysis for the empirical results. As a result, several other avenues were considered to address the deficiency. The white-box mode was thought to provide better judgement with regard to the performance degradation by adjusting the run-time parameters not addressed by the approach. Mi &

Zhang (2015), consequently provided a consolidated assessment guiding principle in terms of network performance, functionality, applications, design and development as well as security to analyze some of the established IPv4/IPv6 transition approaches. The performance assessment measure is normally presumed to be for the equipment including forwarding performance, searching, storage, and network computational overhead. All these approaches put into consideration the fact that there is no one on one mapping of the transition mechanisms and technologies developed by IETF.

When IPv4 was introduced, there was only one type of application traffic with dominancy on the world wide web: emails and FTP files. The kind of traffic was not complex despite the initial network congestion and other network conditions. Contrary, IPv6 was designed to smoothly support both conventional and modern real time traffic. The projected real- time traffic content includes multimedia data, high-definition audio, video, movies and TV programs, VoIP, as well as scientific, environmental, or economic data. The research has been carried out beyond that with visionaries already envisaging 3D super definition (643

Mbps) TV, 3D ultra-definition (2,571 Mbps) TV, 3D telepresence, tele-immersion, virtual worlds and augmented reality. Therefore, the platform was well projected, planned and

9 designed for future systems and applications taken care of. During transition period, many challenges are experienced in the presence of both IPv4 and IPv6 coexistence. Methods have been recommended to evaluate performance parameters with regard to different platforms primarily focusing on hardware compatibility when it comes to IPv6 implementation. The current state of IPv6 usage, IPv4 to IPv6 transition strategies/mechanisms, routing and optimization/performance perspective of this new protocol is the concern (Ali, 2013). Therefore, there is need to address the performance degradation issues arising from the transition process from version 4 to version 6 in the ISP backbone or infrastructure networks.

The transition process from version 4 towards the coexistence of version 4 and version 6 platforms is a difficult process since the users can’t afford to transit at the expense of continuous downtime of the internet. But because the two protocols are not compatible, it is logical to allow both protocols to co-exist for some time to allow the transition mechanisms to mature. With Internet of Things and other emerging technologies, all devices must be connected together and coexist for communication. Several significant factors attributed to performance degradation in the transmission of data packets do exist.

The study sought to enhance the performance of IPv4/IPv6 network coexistence during the transition to balance the transmission of data, video and voice traffic in a heterogenous environment.

10 1.3 Objectives

1.3.1 Overall Objective

The purpose of this study was to enhance network performance for transition from IPv4 to

IPv6 networks.

1.3.2 Specific Objectives

The study was guided by the following objectives:

i. Establish the performance degradation associated with transition mechanisms in

transiting from IPv4 to IPv6 networks

ii. Analyze how the mapping of configuration attributes to transition mechanisms

affect performance degradation from IPv4 to IPv6 networks iii. Develop a model for smooth transition from IPv4 to IPv6 networks

1.4 Research Questions

i. What are the performance degradations associated with transition mechanisms for

transition from IPv4 to IPv6 networks?

ii. How do mapping of configuration attributes to transition mechanisms affect

performance degradation from IPv4 to IPv6 networks? iii. How can a model for smooth transition be developed?

1.5 Research Scope

The research scope was to enhance performance for transition from IPv4 to IPv6 networks with reference to Internet Service Providers running both IPv4 and IPv6 platforms and operating in Kenya. The study developed a model to enhance performance for transiting to

11 IPv6 network environment to expedite the adoption and deployment process. The network environment comprises of the core and the access network. However, the study was carried out on the ISPs core network since it is the backbone for implementation to the end users, systems, hardware, and applications. The backbone network has big real-time network traffic and may discover the findings to be more useful than small /medium sized access network counterparts.

1.6 Significance

The Enhanced Network Performance Metrics for transiting to IPv6 network operations is key towards a smooth transition. The model ensures that the depleted IPv4 address space is streamlined to an expanded IPv6 platform with more connected network nodes to the internet. The findings may have a positive effect in the highlighted areas;

i. Government

Improve operations by streamlining public services to enable bonafide citizens

access to resources. This boosts the quality of education and healthcare delivered

to its citizenry, stimulate environmental and green energy monitoring practices. The

government can effectively use the model to implement phase III for universal

access to ICT services by the National ICT infrastructure. This improves

connectivity and availability of broadband in all the 47 counties in the country.

ii. Internet Service Providers

The ISPs can access more address spaces for allocation to customers. This translates

to more subscriptions and revenue collection through taxes. It collectively

12 intensifies the economic livelihood and job creation for both urban and rural

population. iii. Business enterprises

Growth of the global business with more connections to the internet expanding the

market limits created by the depleted pool of addresses avoiding diminishing

experience for customers and access to supply chain. iv. Telecommunication users

The deliverable promotes remote, mobile, and teleworking as well as foster high

speed equal Internet access for all.

13 CHAPTER TWO

LITERATURE REVIEW

2.1 Introduction

The IP fundamentally obligates logical addressing and IP header fragment coordination activities to facilitate communication over the Internet backbone. This backbone infrastructure utilizes addresses encapsulated in the TCP header to relay data units between two communicating entities i.e. the sender and recipient. The datagram component encapsulates IP header portion as well as the fundamental payload. This section discussed

IPv4, IPv6, transition mechanisms as well as other related technologies and models available today.

2.2 Internet Protocol Version 4

The IPv4 was established and operationalized in early 1980’s (Ali, 2013). This is the

Internet Protocol platform that is used extensively for logical addressing by Internet hosts.

It resides at the internet layer (layer 2) of the TCP/IP stack that acts as a transmission link between entities. Subsequently, when considering the OSI model, it is operationalized at the Network layer (layer 3) fundamentally for logical addressing and routing of traffic between hosts. The IP address assignable to hosts in a network of this kind is identified as a 32-bit address space (Ali, 2013). According to (Ahmed, Mustafa, & Ibrahim, 2015), the contemporary 32-bit address space was considered adequate upon its establishment and operationalization. The 32-bit denotation is an unsigned binary digit, framed in a representation of dotted decimal grouped in 8 bits octet. The sequence of bits is automatically resolved to host names by the Domain Name System (DNS) for internet

14 communication to take effect. The fourth version is comprised of 4,294,967,296 unique addresses assignable to hosts (Albkerat & Issac, 2014) that are classified into several classes as shown in Figure 2.1.

Figure 2. 1: IPv4 classes (Source: (Albkerat & Issac, 2014)

The first three classes (A, B and C) vary the size of bit length addressable to nodes on the network. Consequently, range of addresses within class D are specially conserved to carry out multicast operations. Finally, range of addresses within class E bears the reservation tag for research-based activities and future work. Each of the class cadre has got networks and hosts as shown in Table 2.1. The internet protocol addressing mechanism include a subnet mask identifier to delineate the network identity segment from the host segment of the network address (Babatunde & Al-Debagy, 2014).

Table 2. 1: The addressing scheme (Source: Babatunde & Al-Debagy, 2014).

Class Leading Size of Number of Addresses Start End Address bits network Networks per Address number network bit field A 0 8 126 (27-2) 16,777,216 0.0.0.0 127.255.255.255 (224) B 10 16 16,382(214-2) 65,536 128.0.0.0 191.255.255.255 (216) C 110 24 2,097,150(221- 256 (28) 192.0.0.0 223.255.255.255 2) D 1110 Not Not defined Not 224.0.0.0 239.255.255.255 (multicast) defined defined E 1111 Not Not defined Not 240.0.0.0 255.255.255.255 (reserved) defined defined

The early design and development of the fourth version presumed to have enough quantity

of IP addresses assignable to hosts on the internet. Nevertheless, the new technological

trends that contributed immensely to the development of modern computing devices,

depleted the IPv4 of address pool (Ladid, 2009). Additionally, new developed technologies

and applications have also contributed to the unavailability of IP address. For instance, the

allocation of third generation (3G) mobile network alone can easily accommodate an

approximated one billion addresses. The depletion of the fourth generation address pool

doesn’t suddenly terminate the operation of the internet. It will rather be impossible to

expand the existing network and allocate new addresses to first time devices. This

negatively impacts scalability of e-commerce activities and future innovations (IEEE-

USA, 2009). Almost 40% of the world population today utilize the internet resource as

compared to a paltry1% experienced in 1995.

16 Figure 2.2, demonstrates a steady rise of Internet users accessing online resources from the year 1999 to 2014 and based on the observation it increased ten times. The accessibility gradually increased from approximately 1 billion, 2 billion, 3 billion in 2005, 2010, and

2014 respectively (Stats, 2015).

Figure 2. 2: Internet users in the World (Source: Stats, 2015)

The Google platform collects IPv6 Internet statistics continuously with regard to deployment and rate of adoption. It potentially calculates the IPv6 connectivity index experienced by Google users worldwide. Figure 2.3 clearly shows the trend observed through percentage analysis of bonafide network users accessible to Google over IPv6 platform (Google, 2016).

Figure 2. 3: Percentage of users that access Google over IPv6 (Source: Google, 2016).

Figure 2.4 and 2.5 shows the availability of IPv6 connectivity index experienced in the world and Africa respectively.

Figure 2. 4: IPv6 adoption around the world (Source: Google, 2016).

Figure 2. 5: IPv6 adoption in Africa (Source: Google, 2016).

The adoption of IPv6 in Kenya is 5.07% with Latency/impact of 10ms / 0.01% as per Figure

2.5.

The depletion of IPv4 range of discrete addresses in the four Regional Internet Registries

(RIRs), informed the initiation and adoption of temporary strategies to delay the exhaustion of network addresses assignable to the internet. The primary strategies used were CIDR

(RFC 4632), NAT (RFC 3022), and DHCP (RFC 2131).

2.2.1 Classless Inter Domain Routing (CIDR)

The top on the agenda towards the implementation of this strategy was primarily to facilitate the allocation of assignable IPv4 addresses and consistently routing packets

(Fuller & Li, 2006). The fundamental reason for the directive being to reduce the expansion of routing table entries and updates upon connectivity to the Internet to restrict cumulative and rapid depletion of contemporary addresses.

2.2.2 Network Address Translation (NAT)

The technology behind NAT allows IP addresses to be translated to multiple nodes internally in a network. The NAT translation device utilizes a distinct assigned IP address to take care of the inside network routable to the Internet backbone. Consequently, each host residing in the inside the network has no choice and can be designated any available

IP address (Srisuresh & Egevang, 2001). When packets are forwarded, the translating NAT device interprets the local naming convention to a public internet naming convention

(Cisco, 2004) as evidenced in Figure 2.6.

Figure 2. 6: Network address translation (Source: Cisco, 2004)

Cisco (2004), asserts the NAT interpretation is vital and considered useful for a variety of ways. The consideration could either be assigned automatically or manually. The manual approach is designated to systematically provide the mapping of addresses for both local setup and global setup. As a result, it is singularly vital to nodes whose resource is shared hence the need for a consistent IP address allocated for access to the public network. In this case, the nodes considered may be shared servers, printers, scanners, or any other devices on the network with ethernet capability. The automatic or dynamic approach on the other hand provides IP address mapping functionalities from private to public. The network host stand an equal chance to be assigned any IP address from the list of public IP addresses.

The term Overloading also referred to as Port Address Translation (PAT), is used to map multiple private IP addresses to a single public IP address. This is the typical scenario for connecting nodes to the internet. Multiple addresses can be mapped to a single address because each private address is tracked by a port number (Cisco, 2004). PAT technology utilizes unique source port numbers on the inside global IP address to distinguish between the various translations. The port number is encoded in 16 bits length. The total number of

21 internal addresses that can be translated to one external address could theoretically be as high as 65,536 per IP address. Realistically, the number of ports that can be assigned a single IP address is around 4000. PAT will attempt to preserve the original source port. If this source port is already used, PAT will assign the first available port number starting from the beginning of the appropriate port group 0-511, 512-1023, or 1024-65535. When there are no more ports available and there is more than one external IP address configured,

PAT moves to the next IP address to try to allocate the original source port again. This process continues until it runs out of available ports and external IP addresses (Cisco,

2004).

2.2.3 Dynamic Host Control Protocol (DHCP)

DHCP is a technology cum protocol fundamentally used in internetworking to automatically assign IP addresses to network devices. The process reduces the hurdle of assigning IP addresses manually especially in large enterprise networks. Nevertheless, the shared network resources are not automatically assigned IP addresses for identification, accessibility and consistency by network hosts.

2.2.4 Challenges of the Temporary Approaches

The fourth generation version is considered unreliable and connectionless packet delivery internet protocol. The basic reason behind the presumption is datagrams may be lost, distorted, and/or duplicated during transmission (Droms, 1997). The IP protocol presumes that higher layer protocols will solve the experienced irregularities. However, the fundamental principle of CIDR endeavored to minimize routing table and associated

22 updates in layer 3 devices but instead resulted into routing pitfalls. Consequently, the NAT approach, sought to break the principle of the Internet and at the same time it is not compatible with some applications (Durand, 2001). These three strategic technologies were opted as provisional resolution mechanisms but eventually made the core networks unproductively slower and complicated (Ladid, 2009). Additionally, these short term solutions totally failed to address the fundamental challenge of a depleted address space as pointed out by researchers and industry technocrats.

i. Issues with CIDR

First, the complexity emanates from subnetting of IP addresses into classes. With this strategic technology, the ISP aggregates subnetted Class A and B networks (Ladid, 2009).

The trouble of this approach is that many organizational entities grow in size and as a result there is a higher probability of changing ISPs with the global routing table entries becoming extremely massive, unsuitable, as well as inefficient in execution (RFC 2008). This process calls for a change of all IPv4 addresses for the nodes to reflect the changed network identifier allocated by the Internet provider (Rekhter & Li, 1996). The cost implementation associated with this exercise is extremely high hence it is considered the final course of action by most entities. Furthermore, many organizational entities whose core business is fully supported by Internet connectivity for survival and business continuity, will utilize numerous dispensable ISPs for access. The consequence associated with the approach and taken into account is two Service Providers might personalize network routes that doesn’t belong to either Class A, B, or C addresses. As a short-term antidote, the problem emanated is not insurmountable, since does not exclusively solve the intended obstacles. It

23 experiences similar cost implications with regard to expansion of the routing table size and control of updates as encountered by the class-full routing scheme (Ladid, 2009).

ii. Issues with NAT

The NAT representation fundamentally supports asymmetric principle of data access. The accessibility criteria associated with the Internet architecture solely depend on the local area network extended to wide area network. It is pointed out that in enterprises, all type of data service traversing the medium is internalized to the local area network (Ladid,

2009). Technocrats assume that it is occasional for network nodes in an enterprise to reach outside the local area network. Similarly, the end user will only access data from the public

Internet. As a result, it is evident this implantation strategy consistently breaks this principle. Moreover, NAT principle fail to guarantee security, since the security breaches experienced by computing professionals in organizations occur within the confines of the local area network.

iii. NAT Inhibits Internet Innovation

The asymmetric approach exhibited to data access immensely affects the end-to-end principle of the Internet backbone (RFC 1958). The inability to pay attention to the Internet backbone architecture indicated fundamental problems to the end user. For instance, there are several applications that solely rely on IP addresses for functionality, such as File

Transfer Protocol and Voice-over-IP applications, that are broken down by Network

Address Translation technique (Carpenter & Moore, 2001). There is provision to allow the extension of NAT with application-layer gateways (ALG) whose purpose is to restore the

24 extensive destruction caused by this translation effect. Nevertheless, the implementation of this techniques results into two likely consequences. First, the end user who is the custodian and responsible for new internet applications deployment, is held hostage to liaise and cooperate with NAT vendors for software installation, update, and upgrade. If NAT vendors cooperate and subsequently update the software application, then it implies that the clients running on nonupgraded NAT equipment versions will not manage to utilize the new application platform (Ladid, 2009). Secondly, NAT exhibits important policy framework consequences, since it practically suspends new application implementation.

For instance, the extensive adoption of NAT technology negatively contributed to the shelving of Voice-Over-IP deployment which was extended by a couple of years later.

iv. NAT Interferes with Policy Enforcement

HTTP is a superior protocol with a key obligation in the provision of web surfing hence considered as the principal asymmetric data access protocol. Despite the fact that NAT together with firewall implementation tamper with IPv4 addressing, it is evident that it positively reduces the damage impacted on the inbound and outbound traffic traversing

IPv4 HTTP port 80. The practical scenario applied on the internet is realized by innovative developers who find it fit to utilize port 80 to navigate NATs and firewalls. The only encountered challenge with reuse of HTTP port 80 is that it is proven difficulty to effect policies to Internet traffic traversing at an enterprise’s boarders. For instance, the federal government requires some enterprises, such as financial services firms, to record all interactions with customers. With applications that follow Internet architectural guidelines, such recording is not a problem: the boarder element can monitor requests over

25 communications ports, such as 5060 for SIP or 5190 for AIM. However, with NATs and firewalls present and applications tunneling traffic through port 80, we now have communication traffic masquerading as Web browsing. This reuse of port 80 could inadvertently put the enterprise out of compliance. Likewise, hosts receiving traffic cannot identify the source of the traffic if it is behind a NAT. Such an architecture again may have implications for an enterprise’s ability to comply with federal or local laws, or applicable governance statutes.

v. NAT Impacts Current Generation of Rich Internet Applications

It is noted that the principle of NAT allows multiple clients on a network to share a single

IP address. One key challenge encountered with multiple-client sharing is that there are approximately 64000 IP port numbers available per address. The powerful server equipment overcome the presented challenge by introducing the multiple IP addresses to the public network. Nevertheless, the identified obstacle presented by the port number has become a real challenge for NAT clients, especially those running multiple levels of NAT.

Majority of internet web browsers reliably utilize about four sessions each; while peer-to- peer protocols and applications consumes about four to ten each; electronic mail application consumes two to five sessions each, and so on. Practically, NAT has artificially created a low limit upon implementation which has caused some latest applications, such as Google Maps unsuccessful.

26 2.3 Internet Protocol Version 5 (IPv5) (RFC 1190)

The Internet Stream Protocol (ST) was created in the late 1970's through experimental transmission of multimedia data and distributed simulation by (Krikorian, 2016) stipulated in 1979 in IEN 119 document (Wikipedia, 2016).

The protocol was amended and upgraded after two decades, to ST2 (Topolcic, 1990) defined in RFC 1190 and ST2+ implementation initiated into most of the commercial projects by popular companies such as Apple, IBM, NeXT, Sun, among others. These protocols were connection-oriented, unlike IPv4 suite which supported the connection-less strategy. This protocol guaranteed QoS to applications and services running on this platform. The naming convention for ST and ST+, were already given that magical "5" hence IPv5. The IPv5 was assigned to ST experimental protocol but failed to be introduced for use to the general public.

2.4 Internet Protocol Version 6 (IPv6) (RFC 2460)

This platform was established in 1994 with the main agenda for stakeholder implementations targeted by 1996. The specifications are defined in RFC 2460 of

December 1998 (Deering & Hinden, 1998). It is the main successor version of IPv4 since

IPv5 didn’t see the light of the day for implementation, deployment, and adoption. The design was considered an advancement of the Internet Protocol blueprint with both IPv6 and IPv4 still underutilized. The IPv6 implementation criteria is based on a 128-bit architecture accommodating an aggregate of 2128 addresses (Albkerat & Issac, 2014). The new blueprint is extensively defined in RFC 3513. The protocol evolved from IPv4 address platform. The founding conceptual blue print is considerably maintained with a couple of

27 additional features integrated with the sole purpose to improve network operational excellence and provision of robust service delivery to internet clientele. This protocol fully supports stateless configuration (auto configuration) and NAT is excluded hence considered advantageous.

The IP address blends the MAC address for the interface and the prefix from the router or layer 3 device. The Dynamic Host Control Protocol is not utilized though it can be implemented in the presence of Domain Name System (Albkerat & Issac, 2014). The size of IPv6 address is 128 bits long, encompassing Hexadecimal digits capable of providing

3.8x1038 addresses. These range of discrete addresses are enough to assign a unique address to individual device for the present and the future. The four digits are separated by a colon which provides eight parts; the zeroes can be omitted to make the address smaller as shown in Figure 2.7.

Figure 2. 7: IPv6 addressing (Source: Albkerat & Issac, 2014)

2.4.1 IPv6 Features

Ibikunle & Oshin (2011), affirms that this version has specifically been designed with better features than the outgoing IPv4 address scheme. The successfully executed IPv4 functions were retained in the new scheme. However, new features were added to the IPv4 successful implementation functions to improve performance that is known of the new

28 internet protocol. As a result, it translated into a number of merits over the depleted IPv4 pool as emphasized by (Govil, Govil, Kaur, & Kaur, 2008; Bradner & Mankin, 1995) and defined by IETF in RFC 1752 (Bradner & Mankin, 1995).

i. Larger address space

The fourth generation scheme of addressing utilizes a 32-bit address space assignable to the Internet whereas the next generation platform supports 128-bit address space. This address space has expanded to accommodate all possible end user devices. As a result, the depletion problem of hosts is squarely addressed and hosts reachable. Moreover, this addressing platform has completely eliminated the need for network addresses to be translated and hence reinstating the founding principle of end-to-end mechanism with the mandate of providing some applicable functionalities (Govil, Govil, Kaur, & Kaur, 2008).

ii. Auto configuration of nodes

The advertisements of routes in the routing table is fundamentally based on auto- configuration with regard to link state addressing forwarded by the respective routers

(Govil, Govil, Kaur, & Kaur, 2008). This auto-configuration approach has provided a robust, fast, effective, systematic and dependable network node. The Plug and Play hallmark facilitate automatic setup, installation and configuration of IPv6 network devices.

The node connected on the network establishes a unique string of address identified uniquely derived from a prefixed network code and the associated MAC/physical address.

The importance of this feature is that, the end user is only required to seamlessly connect a device to the network infrastructure backbone in the absence of technical experts. This

29 kind of support is very important especially for connectivity of new smart devices.

Therefore, network devices do not require any form of configuration for connectivity to the network/internet such as manual and dynamic configuration.

iii. More levels of addressing hierarchy

The various addressing tiers considered by the next generation scheme arrangement guarantees satisfactory clustering of routes, more flexible assignment of discrete addresses to downstream nodes and more scalable global routing table suited for the public internet.

iv. Simpler IP header

The intelligence of layer 3 network device helps in the execution of routing and switching capabilities in a faster, effective and efficient manner, with the key purpose improve network performance and optimize processes (Govil, Govil, Kaur, & Kaur, 2008).

Therefore, the complexities associated with the IP header are entirely eliminated.

v. Mobility Support

With the next generation protocol, mobility provision isn’t an exception. The mobile support capability allows network nodes to be assigned one unique IP address that permanently belongs to it regardless of where it is being used. In the process a mobile network device traverse networks i.e. from one network to another, a new IPv6 address is created by incorporating the devices unique IP address and the network’s designation number (Ibikunle & Oshin, 2011).

30 The MIPv4 fundamentally supports triangular routing while MIPv6 on the other hand abandon the routing experience. This capability aid Wireless-Fidelity hosts to pick a new router without renumbering option. As a result, a connection is established that support robustness, dependability and faster link with minimal network congetion and interrupts.

vi. Security

The IPSec fabric implementation proved to be explicitly imperative in IPv6. The framework warrants network nodes of a protected network traffic transmission (RFC

1825). In addition, the embedded security features have no negative effects with regard to performance, speed and network efficiency (Govil, Govil, Kaur, & Kaur, 2008). The embedded security features to the IPv4 protocol were optionally implementation at the user level. The IPv6 platform use data encryption mechanism to secure inbound and outbound traffic. It scrutinizes the integrity of packets with key consideration for interoperability since it is an open standard providing network security policies for packet transmission. It is designed to provide functionality within the seven designated layers of the OSI fabric.

During encapsulation and decapsulation process between the layers, it ensures that the entire block of data units enclosed within the packet is transmitted risk-free among internetworking devices. Therefore, the IPv6 architecture consists of a protocol stack that supports IPSec, enhance security of the network and dispense interoperability framework upon implementation of IPv6 networks. Nevertheless, the provision of IPSec in the next generation is primarily embedded in the extension headers making the execution and implementation optional.

vii. Better Support for Quality of Service

The network Quality of Service sometimes is referred to as "best level of effort" service in the contemporary IPv4 networks and it is an essential ingredient for network performance.

The contemporary implementation experienced drawbacks since it failed to prioritize applications. The criteria used doesn’t distinguish between time-sensitive (streaming video or audio) and non-time-sensitive (file transfer) applications. Time-sensitive applications include streaming live video or audio while non-time-sensitive include applications such as file transfer. For example, in the process datagrams are impaired during transmission, it is evident the TCP segment recognizes the loss and forwards a request for retransmission hence considered a reliable form of transmission. However, regardless of the reliability evidenced, network delay is inevitable. The IPv6 embedded features enhances services delivery, boost security, and improve reliability of the network for better coexistence. The identification of traffic and handling of inbound and outbound transmission is defined in the IPv6 additional fields. In this arrangement, the Flow Label field contained within the

IP header, facilitates data units in a flow to be uniquely identified and dealt with.

Consequently, as the transmission is identified in the header, QoS is guaranteed and supported efficiently. Considering these enhancements, this next generation protocol supports applications to request handling with no delay across the wide area network. This provision allows time-sensitive data to be loaded with minimal latency as supported by the priority levels 0 to 7 as follows:

i. Level 0 - No specify priority

ii. Level 1 - Background traffic (news)

32 iii. Level 2 - Unattended data transfer (email)

iv. Level 3 - Reserved

v. Level 4 - Attended bulk transfer (FTP)

vi. Level 5 - Reserved

vii. Level 6 - Interactive traffic (Telnet, Windowing) viii. Level 7 - Control traffic (routing, network management)

The implementation strategy considered eliminates fragmentation and reduces latency and

extra bandwidth consumption for prompt arrival of packets to the destination. In the long

run, this implementation approach may result to inefficient utilization of traffic-oriented

and resource-oriented traffic.

2.4.2 IPv6 Headers

The IPv4 header size is 20 octets; nevertheless, the appended options field variable length

additionally constitutes the accumulative IPv4 packet size. On the other hand, IPv6 packet

header size comprises of 40 octets. The total of 6 IPv4 header fields successively acquired

from the 12 contained in IPv6. The implementation criterion is in such a way that

unspecified number of fields contained in the prior protocol are camouflaged by

redesigning and adapting the designated names. In IPv6 header, there are additionally new

fields that are added to introduce the new capabilities as shown in Figure 2.8 (Cisco, n.d.).

Figure 2. 8: The comparison of IPv4 and IPv6 header (Source: Cisco, n.d.)

In IPv6 extension header, the basic fragmentation process does not need fields. The IPv6 enabled routers doesn’t support fragmentation of datagrams. This requirement eliminates the routers fragmentation challenges associated with IPv4. With IPv6 network infrastructure, the sending host regulates the maximum capacity for transmission using a network discovery protocol with the view to eliminate fragmentation on the routers. In this approach, the IP header checksum is eliminated from layer 3 (network layer). To add on to the datalink layer strategies, layer four which fundamentally take care of end-to-end connectivity has a checksum ideally for error detection. Consequently, the elimination criteria ensure that the optional provision for the checksum at the upper layer is made mandatory. The IPv6 architectural implementation converts IPv4 options field as well as enforces the required functions using extension headers instead. It is important to highlight

IPv6 header as categorized into diverse fields:

34 i. Version Number: This field consists of a 4-bit field similar to IPv4. It contains

identifier 4 and 6 for IPv4 and IPv6 respectively. It gives a detailed account of the

protocol version, that is RFC 2460 for version 6.

ii. Traffic Class: It is comparable to 8-bit ToS service field for IPv4. It sets out the

class of the transmission traversing the datagram. The numeric denotation 0-7 are

defined for data traffic with congestion control while denotation 8-15 seek to define

audio and video traffic without congestion control. iii. Flow Label: This parameter consists of an additional IPv6 20-bit field used

primarily for tagging packets with a particular flow to differentiate data units at the

network layer. The label identifier uniquely incorporates the integration of a source

address and an appended 20 bits label. As a result, the source allocates the same

label to all packets designated to be part of the same flow. Using this tag that

essentially establishes the path to the network facilitates to route traffic instead of

routing switch (Partridge, 1995). iv. Payload Length: It occupies 16 bits similar to the total length of IPv4. The field

specifies the aggregate length of the data segment of a packet. It consists of the

number of bits constituting the total datagram header and the number of data units.

v. Next Header: this parameter specifies the kind of information that follows the IPv6

header. This is achieved by indicating the type of header which follows the fixed

IPv6 header. This can either be TCP, UDP, ICMPv6 or an optional IPv6 header

type. The field has a length of 8 bits. vi. Hop Limit: The Time to Live (TTL) field of IPv4 packet header is a direct replica

of this field. The Hop Limit field aim to confirm the highest number of hops an

35 IPv6 packet is likely to traverse before it is discarded. It also sets out the validity

period for the datagram or the fragment to coexist in the network without being

dropped. As a result, this parameter aims to guard a datagram from continuously

travelling without being interrupted by any end user. The aggregate length for the

field is 8 bits.

vii. Source Address: It is synonymous to the contemporary IPv4. However, the field

size for IPv6 is 128-bit unlike 32-bit designated for IPv4. viii. Destination Address: Just as the source address, the field for IPv6 is similar to IPv4

packet header Destination Address field. However, the field size for IPv6 is 128-

bit unlike 32-bit for IPv4.

2.4.3 IPv6 Address Types

The next generation network node requires more than one IP address. In RFC 3513 and its

updated version RFC 4291, various types of discrete IP addresses are discussed. These

addresses that supports IPv6 protocol include unicast, anycast or multicast.

i. Unicast: this provision comprises of addressing strategy implemented with one

interface tasked with the sole responsibility of disseminating packets to the

designated address by this unicast address via a known interface.

ii. Anycast: the compatibility platform present on various nodes with similar service

capabilities allows inbound or outbound traffic to be forwarded to the nearest

interface. The anycast address identifier is outlined on a couple of interfaces for

different devices. The traffic forwarded to the anycast address is conveyed to any

interface(s) identified by that address.

36 iii. Multicast: this address has a defined relationship between the nodes and the

interfaces of the nodes. The association is characterized by either a node, more

nodes, an interface or several interfaces. Data traffic is forwarded to the individual

interface designated by the multicast address. The identifier for the addressing

fundamentally defines several interfaces usually from different nodes.

However, in a typical implementation scenario several types of addresses exist as shown in Table 2.2.

Table 2. 2: IPv6 address type (Source: Researcher) Type of Address Description Prefix Global Unicast Globally assigned unicasts to be used 2000:/3 (allocated) Address in the internet 4000::/2 - fc00:/9 (unallocated) Link-Local T These addresses can be used within a Fe80::/10 Address local network, such as an Ethernet LAN. A router can’t forward a packet that has a Link-Local Address in its source or destination address Unique Local These addresses can be used within an Fc00::/7 Address enterprise network or a home. Equivalent to IPv4 private addresses Multicast Used to send a packet to multiple Ff01::/16 (interface) destinations Ff02::/16 (link-local) Ff05::/16 (site-local) Ff0e::/16 (global) Anycast Used to send a packet from a single 2000:620:20:1:: node to the nearest member of a group where all members are identified by the same IP address Unspecified Unspecified ::/128 Loopback Used when a host wants to send a ::/128 packet to itself. IPv4-Mapped Used to embed IPv4 address into an ::ffff/96 IPv6 address 6to4 Prefix used by all hosts that want to 2002::/16 send a packet using 6to4 Teredo Prefix used by all hosts that want to 2001:0000::/32 send a packet using Teredo

37 Type of Address Description Prefix Documentation Used in examples and documentation 2001:db8::/32 Can’t be a source or destination address Benchmarking Used in examples and documentation 2001:0010::/28 Can’t be a source or destination address Orchid Used for experiment

2.4.4. Comparison of IPv4 and IPv6

The determining factor is the amplification of functionalities for logical addressing as well as routing of data packets. The IPv6 platform addresses the addressing problem by increasing the pool of address space from 32 bits to 128 bits to take care of adequate levels of addressing hierarchy and simpler auto-configuration of addressable nodes.

Consequently, the numerical value of discrete addresses ranges from 232 addresses

(4,294,967,296) for IPv4 protocol to 2128 addresses (approximately 3.4×1038, i.e., 3.4 followed by 38 zeroes) designated for IPv6 addressing. It is common knowledge that this type of implementation fundamentally eliminates the problem experienced on the contemporary addressing scheme, render void the contemporary address exhaustion and allot the unallocated IPv4 addresses through the next generation protocol.

Some other remarkable variance is with regard to the routing scalability. The next generation platform replaces the broadcast addressing functionality with multicast addressing capability. The complete IPv6 interfaces essentially contain at least one desirable unicast address. However, a single interface can also have multiple IPv6 addresses assigned and executed concurrently. The arrangement of IPv6 header format has been simplified with some IPv4 header fields abolished hence minimizing the cost implication for processing and routing of the protocol. Considering the numerical

38 superiority, IPv6 address bit length is four times longer than IPv4 addresses, but the design requirement for IPv6 header is only twice larger than the size of the IPv4 header. The next generation platform infuses the options field that can be used optionally; the extension header that eliminates several secondary aspects from the main header and adding them in this space. Extension headers allow multiple services such as Hop-By-Hop Options,

Routing, Fragment, Authentication Header (AH), Encapsulating Security Payload (ESP),

Destination Options and No Next Header. IPv6 also defines new extensions and options that provide additional support for authentication, data integrity and confidentiality as a basic element of IPv6 as described in RFC 4891 since IPSec implementation is mandatory

(Graveman, Parthasarathy, Savola, & Tschofenig, 2007). A new feature is also added to enable the packet labelling such that when the packet belongs to a particular traffic flow for which the sender requests special handling, such as non-default quality of service or real time service, synonymous to a MPLS tunnel. In a nutshell, remarkable amendments are introduced specifically with regard to assignment of addresses as well as IPv6 header options and encoding that facilitates for more efficient packet forwarding and higher flexibility to infuse new options on the architecture for future engagements. Consequently,

Table 2.3 summarizes the comparison between the contemporary Ipv4 and the next generation addressing platforms from different implementation scenarios.

Table 2. 3: Comparison of IPv4 and IPv6 (Source: Researcher) Parameters IPv4 IPv6 Address 32 bits long (4 bytes). 128 bits long (16 bytes). Consist of a network and a host portion. 64 bits for the network and 64 bits for the host. Different address classes are The host portion of an IPv6 constructed: A, B, C, D, or E depending address will be derived from a on initial few bits. MAC address or other interface identifier.

39 Parameters IPv4 IPv6 The total number of IPv4 addresses is 4 The total number of IPv6 294 967 296. addresses are 3,40282E+38

The configuration of IPv4 is The configuration of IPv6 is nnn.nnn.nnn.nnn, where 0<=nnn<=255, xxxx:xxxx:xxxx:xxxx:xxxx:x and each n is a decimal digit. xxx:xxxx:xxxx, where each x is a hexadecimal digit, representing 4 bits. Address mask Used to assign network from host part. Not used Address Used by IPv4 to find a physical address, No ARP as IPv6 use stateless Resolution associated with an IPv4 address. auto- configuration and Protocol neighbor discovery using ICMPv6. Address types Unicast, Multicast, Broadcast Unicast, Multicast, Anycast Configuration IP addresses and routes must be IPv6 interfaces are self- established while configuring a new configuring using IPv6 stateless system to communicate with other auto-configuration to systems. communicate with other IPv6 systems that are local and remote. Domain Name Applications receive host names Same for IPv6. Support for System (DNS) (www.google.fi) and use DNS to get IP IPv6 exists using AAAA address (173.194.32.18). (quad A) record type and reverse lookup (IP-to-name). Applications also receive IP addresses Applications may elect to and use DNS to get host names. accept IPv6 addresses from DNS (or not) and then use IPv6 to communicate (or not). For IPv4, the domain for reverse For IPv6, the domain used for lookups is in-addr.arpa. reverse lookups is ip6.arpa or ip6.int (if not found) DHCP Dynamically obtain an IP address DHCP does not support IPv6. FTP Used to send and receive files Does not support IPv6. ICMP Used to communicate network The same for IPv6 (ICMPv6) information. with some new attributes to support neighbor discovery. IP header Variable length of 20-60 bytes, based Fixed length of 40 bytes & on IP options under consideration. Simpler No IP header options. IP header Many options that might associate with No options but support some options an IP header (before transport header). extension headers: hop-by- hop, routing, fragment, and destination. LAN Used by an IP interface to get to the IPv6 can be used with any Connection physical network. Many types exist; for Ethernet adapters and is also

40 Parameters IPv4 IPv6 example, token ring, and Ethernet. supported over virtual Ethernet Sometimes referred to as the physical between logical partitions. interface, link, or line. Maximum The maximum number of bytes that a Use a MTU of 1280 bytes. Transmission particular link type (Ethernet or The layers need to fragment and Unit (MTU) modem) supports. defragment the packets to send over a link with less than 1280 MTU. NAT Basic firewall functions in TCP/IP. IPv6 does not require NAT as the expanded address space of IPv6. Packet Basic firewall functions in TCP/IP Does not support IPv6. filtering Packet TCP/IP can be built to forward IPv4 IPv6 packets are not forwarded. forwarding packets when they are transmitting on different networks. Ports TCP and UDP have separate port spaces The same as IPv4. However, as in the range from 1 these are in a new address to 65535. family, there are now four separate port spaces. Private and All IPv4 addresses are public, except IPv6 addresses are either public public for three address ranges: or temporary. However, addresses In class A - 10.*.*.* (10/8) temporary addresses, which are In class B - 172.16.0.0 to used to shield the identity of a 172.31.255.255 (172.16/12) client when it commences In class C - 192.168.*.* (192.168/16). communication (for privacy), Private addresses are not routable to the can be globally routed. Internet. Temporary addresses have a limited lifetime and generally identical to public addresses. Route A mapping of a set of IP addresses to a The same as IPv4 but IPv6 physical interface and a next-hop IP routes are associated to a address to forward IP packets using the physical interface as because line. IPv4 routes are associated with an source address selection IPv4 interface. functions differently for IPv6 than for IPv4. VPN Used to extend a secure and private Does not support IPv6. (IBM network over an existing public 2008) network.

2.5 IPv6 Transition Mechanisms

The next generation platform establishment and design failed to support and provide backward compatibility. The IPv6-only devices failed to directly communicate with IPv4-

41 only devices. As a result, there was a dire need to by IETF to initiate the development of transition mechanisms to support this process. The transition technologies are methods that facilitate link communication on IPv4 and IPv6 backbone, since there is no one on one mapping between the two protocols to effect communication. For effective data transmission, key methodological arrangements must be enforced (Albkerat & Issac,

2014). In addition, for combability of all networks heterogeneously implemented it is deemed fit to employ transition technologies for this coexistence (Georgescu, Hazeyama,

Okuda, Kadobayashi, & Yamaguchi, 2015). Therefore, a proposal was made for initiation of three fundamental transition mechanisms namely dual-stack, translation and tunneling.

The associated implementation standards are advanced by (Nordmark & Gilligan, 2005;

Baker, Li, Bao, & Yin, 2011) in RFC 4213 and RFC 6144 respectively and (Subramanian,

2003) as depicted in Figure 2.9.

Figure 2. 9:Transition strategies (Source: Subramanian, 2003)

42 The dual-stack execution allows for both the contemporary and next generation configuration on a single network node. This kind of implementation is preferably deployed in a client/server networking infrastructure. The approach experienced overhead challenges during routing of packets. It requires two routing tables and duplicated routing processes considered bulky on layer 3 devices. Translation strategy aims to achieve interconnection between the two protocols through translation of data unit formats for conformity. However, the challenge with this strategy is that it fragments data unit’s phenomenon meant to be restored by IPv6 and hence the end-to-end fundamental and designated principle of the public Internet. The present-day strategies are rated either as stateless or stateful technologies. The stateful approaches include NAT64 and DSLite whereas stateless include IVI. The stateless approach attains direct connection of one-on- one by only translating two designated headers i.e. the IP and ICMP headers within the data unit. On the contrary, stateful approach generates a one-to-many mapping of IPv4 address by using the IPv4 address resources as a pool on the translating device and allocating them with per port granularity. Stateful translators require a great deal of per state flow maintenance, in other words every incoming packet has to be classified to its corresponding queue, increasing the overhead on the network devices involved. However, stateless translators need one IPv4 address for every IPv6 host, which negates the primary advantage of IPv6: the amplification of discrete range of address spaces.

2.5.1 Dual Stack Transition Mechanism

The execution strategy primarily calls for both IPv4 and IPv6 platforms to operate concurrently, enabling end devices to execute operations on IPv4 or IPv6, with emphasis

43 on applications, services, network availability, and organizational policies (Savita &

Monalisa, 2013; Albkerat & Issac, 2014). The mode of operation of the two protocol stacks is autonomous and therefore all the network components should be compatible with all the schemes. This automatically calls for all contemporary network backbone to be IPv6 compatible. Consequently, if the compatibility framework is not observed then revamping consideration must be put into account for IPv6 readiness. It should also be observed that it is practical for end nodes to operate on both IPv4 and IPv6 backbone but fail to support some applications upon implementation. The contemporary address is translated to IPv6 for compatibility and further execution. Chronologically, 96 bits are replaced by zeroes and the remaining 32 set of bits anatomically forms the valid IPv4 address. The network communication is fully accomplished by both platform hosts. Incase IPv6 hosts are executed then IPv6 is utilized while for IPv4 the reverse is true. Additionally, on implementation the two protocols share layer four. Figure 2.10 shows the dual stack architecture.

Figure 2. 10: Dual stack architecture (Source: Savita & Monalisa, 2013; Albkerat & Issac, 2014).

44 2.5.2 Tunneling Transition Mechanism

The tunneling approach facilitates dual stack in both protocols for effective and efficient communication (Shah, 2015). The communication is initiated by a tunnel for passage of

IPv6 traffic encapsulation over IPv4 backbone and decapsulation of the very traffic upon arrival to the receiving network node (Komal, 2015). This process is made possible by dual stack network connected nodes as shown in Figure 2.11. Originally, the manually configured option played a key role in the management of tunnels. Later on, several other methodologies came into play though experienced overhead challenges. As a result, other methodologies emerged and considered for implementation in specific scenarios either as automatically or semi-automatically. The tunnel for transmission is initiated ideally to provide communication either between two routers, two hosts or host and router.

Figure 2. 11: Tunneling (Source: Shah, 2015).

In addition to these methodologies, IETF in its technical recommendations proposed several other practical approaches affiliated to tunneling. These approaches are Manual

Tunnel, Generic Routing Encapsulation (GRE), 6 over 4, Intra-Site Automatic Tunnel

Addressing Protocol (ISATAP), 6to4, Teredo, and Tunnel Broker.

45 i. Manual Tunnel

In this approach a permanent virtual circuit link is generated fundamentally to link two

IPv6-enabled networks with IPv4 infrastructure in between. The configuration initiated for execution is point-to-point tunnel with static provisions linking the backbone. The tunnel sending endpoint and receiving endpoint is normally IPv4-based dual-stacked, with an

IPv6 address enabled tunnel interface initiated and configured. The arrangement allows

IPv6 data units to be transmitted over the IPv4 backbone infrastructure. The transition strategy failed the expandability test since the associated tunnel does not support automatic configuration. This implementation process is considered expensive and unsustainable if adopted since it amplifies network maintenance costs (Savita & Monalisa, 2013).

Additionally, in the presence of more tunnel endpoint configurations, greater management overhead is experienced.

ii. Generic Routing Encapsulation (GRE) Tunnel

This is a category tunneling with manually configured tunnel source and destination (Savita

& Monalisa, 2013). The tunnel sending endpoint and receiving terminal is normally configured with IPv4-enabled address, dual-stacked while the configuration for the tunnel interface is supported with an IPv6-enabled address. In this process, the created tunnel has an IPv6 packet data unit encapsulated within the GRE header and wrapped inside the IPv4 header. The created GRE tunnel is considered and configured point to point for effective functionality as demonstrated in Figure 2.12.

Figure 2. 12: Generic Routing Encapsulation - IPv4 tunnel (Source: Savita & Monalisa, 2013)

iii. Intra-Site Automatic Tunnel Addressing Protocol (ISATAP)

The definition presented in RFC 5214 technical document by (Templin, Gleeson, & Thaler,

2008) recommended one tunneling mechanism termed ISATAP. Tunneling is an automated protocol that transmits IPv6 datagrams between dual stack hosts on an IPv4 backbone. The key consideration for this strategy was to automatically allocate IP addres ses and establish the tunnel for transmission. Upon implementation of this strategy, the ISATAP router broadcasts address prefixes to determine the logical subnet being used. The hosts connected to ISATAP on the other hand, utilizes the broadcasted prefixes to initiate, configure and execute local and/or global addresses (Komal, 2015). This end devices initiate the reachability acknowledgement messages to enforce reliability. The sender forwards

Neighbor Solicitation messages and the receiver acknowledge by receiving a Neighbor

Advertisement message. The technocrats working with the network upon implementing the infrastructure maintains a Potential Router List (PRL) to constitute broadcasted ISATAP router interfaces. Two hosts lying on the same logical subnets use link-local addresses to establish host-to-host tunnels. However, an ISATAP host requires global address to

establish tunnel with ISATAP router in order to communicate with IPv6 host lying on different subnet as shown in Figure 2.13 (Komal, 2015).

Figure 2. 13: Components of Intra-Site Automatic Tunnel Addressing Protocol tunneling infrastructure (Source: Komal, 2015).

iv. 6to4

Carpenter & Moore (2001) submitted an automatic tunneling mechanism termed 6to4 a n d d e f i n e d b y IETF in RFC 3056. The 6to4 approach, proposes IPv6 data to be transported across IPv4 backbone. Currently, this is the most widely used tunneling technique (Bahaman, Hamid, & Prabuwono, 2012). It requires a global address prefix

(2002:WWXX:YYZZ::/48) for execut i on by end devices for automatic configurations. During tunnel initiation and implementation normally, there is no end device configuration and router configuration is maintained at a bare minimum. After IP address configuration, the network node can communicate with other nodes and routers in the IPv4 backbone or with IPv6 nodes existing in the IPv6 backbone (Komal, 2015). The host fundamentally forwards IPv6 data units to the 6to4 router, destined to other 6to4 router or an IPv6 node. Finally, the router encapsulates the packets using its tunneling interface. If the destination is a 6to4 host/router existing in the IPv4 internet, the

48 decapsulation of tunneled packets is performed by destined 6to4 host/router as shown in Figure 2.14.

Figure 2. 14: Components of 6to4 tunneling (Source: Komal, 2015)

Figure 2.15 shows an IPv4 tunnel implementation configured on interface 0/0 with IPv6 prefixes 2000::1/64 and 2000::2/64 for inbound and outbound traffic respectively, with

IPv4 addresses where translation happens from IPv4 to IPv6 before packets are forwarded to the next hop (Shaneel, Salman, Avinesh, Ruchinav, & Khan, 2016). In this tunneling setup, the IPv6 host sends packets over the IPv4 network to another IPv6 host. The packets are encapsulated at the edge of router1 from IPv6 to IPv4 packet and router 2 decapsulates

IPv4 packets to IPv6.

Figure 2. 15: 6to4 network implementation diagram (Source: Shaneel, Salman, Avinesh, Ruchinav, & Khan, 2016)

In 4to6 approach, IPv4 hosts communicate over IPv6 network backbone. The 6to4 and 4to6 both encapsulate the packets at the router and hence router to router encapsulation.

v. 6 over 4

The 6over4 strategy is implemented based on the IPv4 multicast tunneling approach

(Albkerat & Issac, 2014). It is an automated host-to-host, host-to-router, and router-to-host technology used to provide unicast and multicast IPv6 connectivity between IPv6 nodes across an IPv4 backbone. In this approach, the hosts use a valid 64-bit prefix for unicast addresses together with the interface identifier: WWXX:YYZZ, where WWXX:YYZZ is the colon-hexadecimal representation of the IPv4 address (w.x.y.z) assigned to the host.

By default, 6over4 hosts automatically configure the link-local address

FE80::WWXX:YYZZ on each 6over4 interface. 6over4 treat an IPv4 backbone as a single link with multicast capabilities. This is an implication that Neighbor Discovery processes are executed similar to a physical link with multicast capabilities. To emulate a multicast- capable platform, the IPv4 backbone must be IPv4 multicast-enabled. The compatibility of

50 IPv4 multicast is not generally available on all networks, hence scalability issues are inevitable. Therefore, it is an ideal method for implementation of small self-contained networks with the presence of multicasting. According to Wu, Cui, Wu, Liu, & Metz

(2013), there are two important protocols to use with this technique, namely SLAAC and

ND. However, ND causes security concerns because the ND message might be comprised and attacked.

vi. Teredo

Teredo tunneling technique resolves the concerns emanated from NAT traversal as proposed by (Huitema, 2006) and defined in RFC 4380. The Internet Assigned Numbers

Authority (IANA) provided a global address prefix 2001::/32 to Teredo, with the sole purpose of auto- configuration of addresses to clients. Consequently, a fter address configuration, two Teredo clients located in different sites can communicate with each other. Initially, a Teredo client sends an empty packet to another Teredo client, to create a source- specific entry in NAT translation table (Komal, 2015). In the event a cone NAT

(one to one NAT) is experienced, the data units will be routed to the Teredo client and forward an acknowledgement to the sending entity using the entry created in the NAT translation table. In the presence of a restricted NAT, an entry will be created in the NAT translation table corresponding to sender as shown in Figure 2.16. However, the packet will be discarded under this arrangement.

Figure 2. 16: Components of Teredo tunneling (Source: Komal, 2015).

vii. Tunnel Broker

A different approach was proposed by (Durand, Fasano, Guardini & Lento, 2001) to aid in tunneling, referred to as Tunnel Broker with its definition in (RFC 3053; RFC 5572). Its sole purpose was to precisely to articulate the challenges created by automated tunneling approaches and to provide an enabling environment to ISPs management by creating a central Tunnel broker. This technique, (Komal, 2015) requires a client to register with the

Tunnel Broker. After registration, the client can then probe for the tunnels from the broker on a need basis. The client is authenticated before receiving services from the Tunnel

Broker. The tunnel is established to communicate with IPv6 nodes with IPv6 backbone.

After authentication, the client node forwards request to the Tunnel Broker (Komal, 2015).

On receiving the request, the Tunnel Broker acknowledges by assigning a global IPv6 address to the client. This is followed by registration in the DNS for resolving of the IP address to hostnames. Depending on the load, it chooses a Tunnel Broker, configures the server side of the tunnel, and allocates a lifetime for the tunnel. The tunnel configurations

52 are returned to the client, in the form of executed scripts. Finally, the client establishes a tunnel with the Tunnel Server with the aid of these configurations as shown in Figure 2.17.

Figure 2. 17: Components of tunnel broker tunneling infrastructure (Source: Komal, 2015).

2.5.3 Translation Transition Mechanism

Translation refers to the conversion of IPv4 addresses to IPv6 addresses or vice versa. The approach changes the IP packet from IPv4 to IPv6 and inversely, with regard to the source and the destination. The technique converts the header and payload of IP packet from version 4 to version 6 and vice versa. The translation can either be stateless or stateful

(Arafat, Ahmed, & Sobhan, 2014). The stateless form of translation, has no reference to the pervious packet during the conversion while stateful form translation maintains a relation with the previous IP data units. The techniques include Network Address

Translation Protocol Translation (NAT-PT), Stateless IP/ICMP Translation (SIIT), Bump in the stack (BIS), and Bump in the API (BIA).

53 2.5.3.1 Stateless IP/ICMP Translation (SIIT)

This technique performs its executions with the functional header between IPv4 address and IPv6 address. The key challenge with this approach in the translation process is that the information might be lost and NAT isn’t eliminated (Albkerat & Issac, 2014). All IPv6 nodes are required to be assigned IPv4 address hence it doesn’t solve the problem of address pool depletion. This implementation is performed using two addressing approaches, namely, IPv4 translated address for IPv6 node and IPv4 mapped address for the IPv4 node.

In the first approach, the creation of IPv6 address by appending the prefix 0:ffff:0:0:0/96 before the IPv4 address. In the second approach, for IPv4 mapped address of IPv4 host, the IPv6 is created by appending ::ffff:0:0/96 before the IPv4 address. After this process, translation is required for effective the communication of terminals. During the translation stage, the IPv4 data unit is translated to IPv6 data unit with the source taking up the prefix:: ffff:0:0/96 and the destination taking up the prefix 0:ffff:0:0:0/96. It is then eliminated from the original data unit. Consequently, the DNS should be aware of the addresses fundamentally for host name resolution. The local DNS server in this arrangement helps the IPv6 node to learn the presence of IPv4 mapped address in order to get ‘AAAA’ record from ‘A’ record using DNS64. However, the IPv4 record is registered within IPv6 hosts precisely to answer the heterogeneous query. The challenge is that there is no security considered for the network by this method; the DHCPv6 and the SLAA can as well be used to assign the IPv6 addresses for the host. (Ge, Mi, & Wu, 2014). Due to the security challenge, this technique is not recommended (Monte, et al., 2012).

54 2.5.3.2 Network Address Translation - Protocol Translation (NAT-PT)

The packet transmission and communication for this technique allows to have a pool of global IPv4 and IPv6 prefix with 96 bits length. The process to be followed for translation is achieved by allocating the pool of IPv6 address with the IPv4 address through NAT-PT gateway (Ahmad & Yaacob, 2012). This approach is independent, it does not call for extra applications or rely on other transition mechanisms. However, backbone interoperability is necessary for effective management practices (Chen, Chang, & Lin, 2004). Figure 2.18 illustrates the NAT PT implementation in the backbone.

Figure 2. 18: Network Address Translation - Protocol Translation (Source: Bi, Wu, & Leng, 2007)

The added prefix ::/96 is of great importance in the generation of a new address. For translation between IPv6 and IPv4 platforms to be achieved, the source IPv4 will be created from the source of IPv6 and the subsequent port is located by looking it up in the NAT binding table. Consequently, the destination IPv4 address is created by discarding the prefix from the address. In addition, to translate from IPv4 address to IPv6 address, the prefix will be appended to the IPv4 source address to form an IPv6 source, and the destination address is generated using the destination IPv4 address and the port looked up

55 in the NAT binding table. Therefore, the key design issue is to eliminate the problems associated with building of the binding map and the heterogeneous addressing will use the

DNS ALG on the translator. This ultimately help to convert the A to AAAA query in two- way to generate a stateful binding between IPv6 and IPv4 using the pool of addressing

(Wu, Cui, Wu, Liu, & Metz, 2013).

2.5.3.3 Bump in the Stack (BIS) and Bump in the API (BIA)

These are stateful translations used to solve problems when IPv4 based applications want transmit data units towards IPv6 node remotely located through the next generation backbone network. The implemented approach artifices the application utilizing IPv4 platform on the basis that the routable node is also running on IPv4 protocol. The trick in question fundamentally is generated by the software component and for execution purpose appended within the node. The security provision is not sufficiently strict especially with

DOS attack threat initiated by the domain name system resolution query through depletion of the pool of IPv4 and hence the binding table will be full (Wu, Cui, Wu, Liu, & Metz,

2013).

BIS technique utilizes the translation based on the data units. The translation performs the execution by generating the source address from the host and the destination from the binding table with an IPv4 destination address. Upon reaching the host, the translator now translates the data packet to IPv4 and the source address is taken from the binding table with the IPv6 source address and the destination from the host IPv4 address, as shown in figure 2.19 (Wu, Cui, Wu, Liu, & Metz, 2013).

Figure 2. 19: Bump in the Stack (BIS) (Source: Bi, Wu, & Leng, 2007).

The translation process between IPv4 and IPv6 is finally accomplished by inserting BIS in the dual stack for the host and the IPv4 is detected to the IPv6 (Bi, Wu, & Leng, 2007).

BIA operation is synonymous to BIS upon implementation. BIA technique uses the translator to perform translation operation between the APIs for the two protocol suites.

The mapping and resolving of addresses are similar to those implemented by BIS, though the main functionality of the mapper is to carry out the translation process. This process is executed without the IP header for security consideration of breaking the end to end principle of the Internet (Albkerat & Issac, 2014).

2.5.4 Evaluation of Transition Methods

The assessment criteria for evaluating the transition methods has proved to be relatively diverse. The fundamental consideration can be to analyze the individual characteristic with regard to the pros and cons experienced in the facilitation of end users to designate the suitable implementation scenario for each method. Table 2.4 and Figure 2.20 demonstrates

57 the bear comparison of the transition methods specifically Dual Stack, Tunneling, and

Translation approaches.

Table 2. 4: Comparison of transition methods (Source: Nguyen et al, 2012) Methods Advantages Disadvantages Tunneling Configure tunnel endpoints Face another problem of NATs only Take more time and CPU power Simple deployment Harder to troubleshooting and network No additional management management Have single points of failure Vulnerable to security attacks Translation The router is used as a Limitations similar to IPv4 NAT translation communicator Reduction in the overall value and Solve network utility of the network. interoperability problems Harder to control on a larger scale Complexity increases in IP addresses Dual Stack Easy to implement Two routing tables Low cost Additional memory and CPU power Greatest flexibility Two firewall sets of policies Already supported in all OSs and devices

Figure 2. 20: Comparison of transition methods

2.6 Technological Advances in IPv6 Implementation

The dire need for technology has led to major advances in computing initiated and driven by the technical group of dedicated individuals and corporates in computer networking.

Consequently, several models were designed and implemnted by some service providers.

These included the Dual-Stack Model, Hybrid model, and Service block model as discussed.

59 2.6.1 Dual-Stack Model

This model borrows its implementation from dual stack transition mechanism. The IPv6 implementation in this model can be executed on a platform where IPv4 is activated together with the key accompanying features necessary for a secure, routable, and available

IPv6 network (Cisco, 2010). Sometimes IPv6 is not activated on specific interfaces because legacy support capabilities of devices do not support IPv6 platform. Consequently, it is also possible that IPv6 might be operational on inbound/outbound interfaces of network devices that are needless of IPv4 support. The key motivation for discussion is to ensure that, IPv6 hardware support is guaranteed for successfully execution and implementation practices. The bandwidth and throughput of a connection depend on many parameters such as the number of active users, type of applications, latency and jitter. Because of the enormous data requirements in dual stack implementation environment, Cisco does not recommend having IPv6 unicast or multicast layer switching on software forwarding-only platforms (Cisco, 2010). Figure 2.21 presents the implementation of a Dual stack model in a data center setup for both IPv4 and IPv6 platforms.

Figure 2. 21: Dual stack model (Source: Cisco, 2010)

60 2.6.2 Hybrid Model

According to (Cisco, 2010), the hybrid model integrates more than one independent transition techniques having the same deployment design criterion across the platform infrastructure. This approach is flexible in the sense that the combination of several transition strategies can be applied to accommodate any implemented network. The hybrid approach tries to adapt to the features of the underlying network infrastructure. The adopted transition strategies are adopted putting in consideration a couple of criteria. These include

IPv6 support, number of connected end devices, utilized applications, IPv6 resources location and network infrastructure of various transition strategies. There are three most known and implemented IPv6 transition strategies explored by this model. These include:

i. Dual-Stack: It deploys two protocol stacks, i.e. IPv4 and IPv6.

ii. ISATAP: It is a tunneling strategy that establishes connectivity between the hosts

to router relying on an existing IPv4 backbone. iii. Manually-configured tunnels: establishes connectivity between router to router

relying on an existing IPv4 backbone.

This model focuses on two implementation scenarios combining dual stack/ISATAP and dual stack/manual-configured tunnels as shown in Figure 2.22.

Figure 2. 22: Hybrid model example (Source: Cisco, 2010)

2.6.3 Service Block Model

This is a unique model whose implementation serve as an overlay network that smoothly coexists with IPv4 backbone. The implementation design is centralized, can be deployed rapidly with IPv6 support, support for Quality of Service and the basic access primitives to

IPv6 resources with some operational amendments of core IPv4 backbone (Cisco, 2010).

The model can also be decentralized once the existing platform attains IPv6 compatibility.

The interface used in this strategy is dual-stacks instead of tunnels for connectivity. The presence of dual stack support on all the layers, permit this technique to be fragmented and re-allocated for other functionalities. The hardware deployment necessity the model depends fundamentally on a redundant Cisco catalyst 6500 switches promoted by

Supervisor 32 or 720. For the purposes of scalability, stability and redundant connection on implementation, a high-end switch, supervisor, and modules are configured to handle the impacted load of the ISATAP, configured tunnels (manual) and dual-stack portions of the network. However, for load balancing the increase in the number of configured tunnels

62 and throughput, uniformly distributes the load across an additional pair of switches within the model for balancing.

In practice, there are many similarities between the service block model and the hybrid model. The reason is IPv4 network under consideration is used as the backbone for the

IPv6 network being deployed. The ISATAP platform ensures that accessibility is provided to hosts in the access layer (Cisco, 2008). The configured tunnels (manual) on the other hand are used from the aggregation layer for the provision of accessibility to IPv6 applications and services located in the access layer. The logical addressing and routing of

IPv4 packets is configured between the core layer and model switches to facilitate visibility for the purpose of terminating IPv6 into IPv4 tunnels. However, during implementation the extreme case is analyzed in the absence of IPv6 capabilities in the access, distribution, or core layers of the campus network. The model implementation scenario used in this document has the switches directly connected to the core layer via redundant high-speed links as illustrated in Figure 2.23.

Figure 2. 23: Service block model implementation example (Source: Cisco, 2010)

63 2.7 Performance Metrics

There are a variety of metrics used to analyze data networks. For quantifying network performance, the study has considered Throughput, Packet Loss, Latency, and Jitter feasibility metrics. The performance implementation varies the units of measurement.

Considering the current implemented networks, the measurement unit for latency and jitter is millisecond (ms), throughput is megabits per second (Mbps) while packet loss is the lost frames percentage.

2.7.1 Throughput

Throughput is defined as the successful delivery of data units (number of bits) through the network to users. Equation 2.1 indicates throughput is calculated, where ‘packetSizei’ is

th the total packet size of the i packet reaching the destination, ‘PacketStarttime0’ is the time when the first packet leaves from the source and ‘PacketArrivaltimen’ is the last packet arrival time. This is measured in packets/second, bits per second (bps), channel utilization

(%) and packets/slot.

Equation 2. 1

2.7.2 Latency

Also referred to as average packet end-to-end delay, latency is the total time taken by a data unit (packet) to travel from the sender (source) to the receiver (destination). The attributes of delay can consist of transmission delay, processing delay, queuing delay and

64 propagation delay. End-to-end delay is measured as the difference between the arrival time and sending time of a packet. Equation 2.2 gives the average packet end-to-end delay.

Equation 2. 2

2.7.3 Jitter

Jitter is the variation in packet arrival time measured in seconds. It can be calculated using packet end-to-end delays. It is a crucial parameter for determining network’s performance and QoS that a network provides. It is also generally utilized as an indicator of stability and consistency of network. Equation 2.3 indicates the method of calculation of average jitter.

Equation 2. 3

2.7.4 Packet Loss

This is the unsuccessful delivery of packets from source to destination due to transmission impairments, incompatibility of data formats, and network performance overhead of nodes.

The data units (packets) for transmission are discarded in the presence of network congestion. Packet loss is relative to applications in computing. In data communication, some applications are tolerant to packet loss while others withstand to a particular degree.

For instance, voice applications, can tolerate up to 3% packet loss (1% is optimum) during conversation. Equation 2.4 shows the packet loss ratio calculation explained as the number of ratio of packets lost to the number of total packets transmitted. In the equation, N is the

65 total packets transmitted in a particular period of time and NL is the packet lost number in the same period of time (Mohammed, Adnan, & Hawraa, 2013).

Loss packets ratio = (NL / N) × 100%

Equation 2. 4

2.8 Conceptual Framework

The holistic purpose was to study network performance for transition from IPv4 to IPv6

Networks. The implementation of IPv6 network infrastructure is geared towards network performance metrics; latency, jitter, throughput and bandwidth. The metrics were used in the design of an overall model to help get the best optimal solution to the design towards smooth transition from IPv4 to IPv6 heterogenous network as indicated in Figure 2.24.

Independent Variables Dependent Variables

Bandwidth Transition Performance Mechanisms

(6to4 Tunneling) Throughput Performance Model

Latency Configuration Performance Attributes (Physical Connectivity, Jitter Addressing Plan, Performance Routing Plan, Service Plan, Convergence, Moderating Load Balancing) Variables ▪ Hardware Compatibility ▪ Technical Expertise ▪ Cost of Implementation

Figure 2. 24: Conceptual framework (Source: Researcher)

66 The independent variable was considered to be the IPv4 internet backbone infrastructure with transition mechanism and configuration attributes (physical connectivity, addressing plan, routing plan, service plan, convergence, load balancing) as key parameters for consideration. The IPv6 Network Performance Metrics (latency, jitter, throughput and bandwidth) were considered as the dependent variables. These two protocol platforms cannot coexist side by side and therefore we cannot attain a direct mapping from IPv4 to

IPv6 because of different header sizes and IPv6 support in the legend network systems. As a result, the transition mechanisms are employed to facilitate this process.

2.9 Knowledge Gap

Tunneling implementation causes the network to suffer delays associated with encapsulation and decapsulation process of datagrams. There exist some significant delays that infuse performance bottlenecks during the transmission period of datagrams leading to the deterioration of network performance. The cost involved in the implementation of this strategy with dual stack enabled devices in the network is exorbitant. The network nodes require powerful processors supported with significant computation power which might rarely be feasible for some ISPs for subsequent implementation. Dual Stack hosts need to process two protocol stacks demanding rapid fast processing power. During the translation of packet headers, a lot of information is dropped and gets lost. This information may also be vital for the data packet. This introduces security leaks in the data packet. The execution of service block model and hybrid model poses some design demerits similar to each other upon implementation. The two designs exhibit high cost of equipment required in the design and implementation.

67 There is existence of supplementary cost overheads associated with the layer 2 service block devices, ports for connectivity to the core switches, and other software expenses.

Due to the disadvantages experienced during implementation of the two models (hybrid and service), the dual-stack model remains the darling approach with accolades for implementation by some technocrats in the computing world. Giant corporations consequently showcased during the World IPv6 Launch that it is equally possible to successfully design and implement dual-stack for execution of large-scale networks. In a nutshell, IPv6 has both advantages as well as drawbacks as compared to IPv4 from the performance and security point of view. The literature extensively brings out several issues over IPv4 and IPv6 header structure and justified why the next version of the Internet

Protocol IPv6 is inevitable. These techniques demand optimization in hardware and software like enhancing router software, operating systems etc. The similarities help in implementing strong security policies to secure IPv6 networks. It is expected that IPv4 and

IPv6 hosts will need to coexist for a substantial time during the steady migration from IPv4 to IPv6.

2.10 Summary

The transformation from the contemporary to the next generation platform it is not a walk in the park since the end users can’t afford to transit at the expense of continuous downtime of the internet. But because the contemporary and the next generation architectures are incompatible, both protocols need to co-exist for some time to allow the transition mechanisms to mature. The transition process has not been secure and there are performance degradation challenges with the transmission of data, voice, and video traffic.

68 CHAPTER THREE

RESEARCH METHODOLOGY

3.1 Introduction

This chapter describes the formulation of a research design and methodology adopted to achieve the stipulated goals for the study as outlined in Chapter One. It presents the research methods employed under the chosen research strategy and the research instruments. These include the chosen evaluation methodology in comparison with the other methodologies and justification of the chosen method. After considering the objectives of the study, the level of ISP IPv4 to IPv6 transition in Kenya, the research questions, the limitations and the scope, the researcher felt the appropriateness for adopting both the qualitative and quantitative data gathering techniques i.e. the content analysis method, using the documents, oral communication, and graphics as the instrument and supported by qualitative data obtained through structured interviews. A combination of these research design helped to provide more data to work with and ultimately a more accurate evaluation.

3.2 Research Design

The study employed experimental design to ascertain the transition strategies employed by

Internet Service Providers running both IPv4 and IPv6. The study also established the compatibility of such mechanisms with the current platforms, level of preparedness, and the associated performance issues. The experimental design with simulation was adopted for better, faster and a more enhanced solution through empirical measure of the process.

Simulation is one of the important technologies in this modern time. There are so many

69 objects in real or hypothetical life (Gambhir & Tomar, 2014). The network can also be simulated on the computer and a network simulator is a technique of implementing the network on the computer. The goal of using any simulator is to accurately model and predict the behavior of a real world system (Sarkar & Halim, 2008). Computer network simulation is often used to verify analytical models, generalize the measurement results, evaluate the performance of new protocols that are being developed, as well as to compare the existing protocols. The large scale utilization of simulation packages for modeling and performance evaluation of computer and data communication networks has increased tremendously in the recent past (Fantacci, Pecorella, & Habib, 2004). This is not only due to the availability of sophisticated simulation software packages and low-cost powerful personal computers (PCs), but also because of the flexibility in rapid model construction and validation offered by simulation (Sarkar & Halim, 2008). The major criterion considered important in this study was the ability to integrate the simulation tools in

OPNET Modeler 17.5 and the associated case tools.

There are three different methods for performance evaluation of systems: Computer simulation, mathematical analysis, and real world measurements (Wehrle, Günes, & Gross,

2010). Each of these methods has its own advantages and disadvantages. To accurately analyze system performance using real world measurements the system needs to be implemented first. On the other hand, for mathematical analysis and computer simulation, a model is used instead to achieve the objective. It’s quite clear in terms of input cost and effort that computer simulation and mathematical analysis are advantageous compared to real-world measurements. However, all these methods are used in different scenarios in the study. Consequently, due to the increasing complexity of systems, mathematical analysis

70 becomes intractable and as a result computer simulation is often used. Simulation is deemed important both for comparison of different design alternatives of a system in development and for optimization of existing system designs.

Several types of simulations do exist for network simulation and modeling. These include discrete-event simulation (event-driven), continuous simulation, Monte Carlo simulation, trace-driven simulation, among others (Wehrle, 2010). For computer and telecommunication network simulation the most used method is discrete-event simulation

(Breslau et al., 2000). Unlike continuous simulation, state of an entity in a discrete-event simulation can change only at discrete points which are named events. The discrete-event simulation has been used for research on all seven layers of OSI model, from application, presentation, session, transport, network, data link and physical layers. The key advantage of the simulation platform is that it suites computer networks well and it is very easy to implement.

There are several network simulation softwares used in telecommunication and computer networks today (Pan, J. & Jain, R., 2008). These include OPNET, OMNet++, QualNet,

NetSim, ShunraVE, Ns-2, GloMo-Sim, P2P- Realm, GTNetS, and AKAROA. These are powerful simulators used in different environments to execute and achieve the required outcomes. Although each of the listed simulation tool has its pros and cons, the choice of the tool was often based on the suitability and fitness of the simulator to achieve the required outcomes. In this study, the researcher employed OPNET Modeler version 17.5 to setup, configure, and implement the required scenarios (Siraj, Gupta & Rinku-Badgujar,

2012).

71 OPNET Modeler is one of the industry’s leading simulators, specialized for the purpose of network research and development. Developed by OPNET Technologies, OPNET provides a rich library of models for implementing both wired and wireless simulation scenarios. It assists with the testing and design of communications protocols and networks.

OPNET also provides a graphical editor interface to build models for various network entities from physical layer modulators to application processes. The components are modelled in an object-oriented approach which allows naturally easy mapping of any kind of system. OPNET is widely used by both commercial and academic research communities.

72 Table 3. 1: Comparison of popular network simulators (Sarkar & Halim, 2008). Simulator Type Deployment Network Impairments Network Mode Topologies

OPNET Commercial Enterprise Link models, LIFO, FIFO, ATM, FDDI /academic Priority, queuing TCP/IP, Ethernet, WLAN QualNet Commercial Enterprise Protocol evaluation LAN, WLAN, WAN NetSim Commercial Large scale Collision handling and WLAN, Ethernet, /academic detection TCP/IP, ATM ShunraVE Commercial Enterprise Latency, jitter, packet loss P2P, N-tier, mesh

Ns-2 Open source Small scale Congestion, queuing, Routing, routing, multicast Multicast, TCP over WLANs GloMo-Sim Open source Large scale WLANs, channel models Wireless networks OMNeT++ Open source Small scale Latency, jitter packet loss Wireless networks

P2P- Realm Open source Small scale P2P network, resource P2P discovery

GTNetS Open source Large scale Packet tracing, queuing P2P, ethernet, methods, RNGs. wireless links. AKAROA Open source Small scale Protocol evaluation Bus, Ethernet /academic

A practical functionality of IPv6 network performance and optimization with regard to

traffic optimization, is the actual mapping of traffic onto the network infrastructure to

achieve specific performance objectives tied to traffic and/or resources. The aspects of

traffic optimization that are of interest concerns the utilization of network resources to

enhance traffic oriented performance characteristics during switching and routing process.

As a result, the configuration test bed was setup based on the transition mechanism

implemented by the internet service providers in context. This was accomplished in

OPNET Modeler simulation environment. The essence of the configuration test bed was to

73 help capture and analyze TCP/IP traffic IP packets (at layer 3) alongside traffic performance parameters – packet loss, throughput, latency and jitter between multiple destinations.

Therefore, layer 3 probes (packets) were injected into the ISP simulated network from one point (source) to another (destination). The performance evaluation of findings was based on thorough comparisons of TCP/UDP protocol statistics in several set scenarios. The TCP protocol is implemented on layer 4 functionalities of the OSI model. The UDP protocol on the other hand is a connectionless transport layer protocol that support network applications such as DNS, TFTP and VoIP protocol. The traffic performance metric parameters were measured based on the implementation of the service providers. The model was developed, implemented and tested based on the same traffic performance metric parameters for comparison and to improve resource utilization for better system performance.

3.3 Research Population

In this study, the researcher utilized ISP professionals in the field of computer networking as participants on ground of their specialized expertise, support, and continuous working in the networking industry. The population for the study was on Internet Service Providers

(ISPs) backbone networks operating in Kenya. The researcher collected data from Internet

Service Providers (ISPs) running both IPv4 and IPv6 platforms.

3.4 Sampling Technique

The study used non-probability sampling technique for investigation since the research domain was quite small. This sampling procedure was considered for identification and

74 selection of knowledgeable and experienced participants. As a result, purposive sampling approach was used to select Internet Service Providers (ISPs) running both IPv4 and IPv6 in their backbone. The main goal was to focus on particular characteristics of the population that were of interest to answer the research questions. It was used on the target population since IPv6 is a new field that had not been implemented fully by most of the institutional and corporate networks.

Expert sampling type of purposive sampling technique was used in the study to glean knowledge from participants with particular expertise in IPv4/IPv6 backbone networks and the transition process. The expertise was required in the study to potentially highlight new areas of interest and opening doors to other participants. This was informed by lack of empirical evidence in IPv4 to IPv6 transition process and high levels of uncertainty, as well as long period of time before the findings were uncovered from the study.

3.5 Sampling Frame

The study sampled the size to comprise all the eighteen (18) ISPs in Kenya running both

IPv4 and IPv6 in their backbone network. The researcher continued to sample more cases until no new information was obtained and a saturation point attained. It was based on the saturation principle of diminishing returns, the notion that each additional unit of information would supply less new information than the preceding one until new information dwindles to nothing. In this study the saturation principle holds true and it can be confirmed. The number of participants were sufficient and enough information was provided to enable the researcher to compile a reliable and valid research instrument for this study.

3.6 Data Collection Methods

The researcher combined content analysis and interviews as the main data collection tools.

The researcher was not able to access the production network of the ISPs, citing third party access restrictions as stipulated in the information policy. The researcher systematically extracted and recorded performance metrics, events, behaviors, and artifacts for the study at layer 3 to measure TCP traffic performance parameters - bandwidth, throughput, latency and jitter between multiple destinations. This was nonjudgmental, noncontrolled concrete descriptions of the ISPs operational states.

3.6.1 Content Analysis

The content analysis method enables the analysis of data in a structured manner and it may be used in both qualitative and quantitative studies (Neuendorf, 2002). The quantitative content analysis technique was used in the study to make valid and reliable inferences from the collected data to its context (Krippendorff, 2004). Therefore, this study employed qualitative analysis to interpret the ISPs setup and configurations.

The limitation of authors to provide a number of speculative answers to the questions can be lessened if combined with another method, more appropriate to measure the aspects.

This method may be experiments, surveys, interview etc. (Holsti, 1969). Therefore, in this study content analysis was supported by interviews. Data was collected from the implementers and users in the Internet Service Providers environments running both IPv4 and IPv6 platforms. This was in regard to the performance metrics with focus on traffic

76 oriented (e.g. packet loss, delay, delay variation and throughput) and resource oriented

(bandwidth) optimization perspectives.

The study analyzed content associated with any text or multimedia material with regard to

IPv4/IPv6 network setup and performance metrics. This content was from published technical papers, RFC documents, oral communication, graphics, network printouts, performance reports, and system logs produced by ISPs in the context of network evaluation or content generated by network performance analysis tools. The content analysis involved the following steps:

i. The preparation of a content analysis coding schedule. This comprised of a table

where each row forms a unit for data collection. Each column forms a theme for

the analysis based on the highlighted evaluation questions.

ii. The production of a coding manual. The coding manual consist of a listing of codes

for each of the categories valid for each theme. The manual accompanies the coding

schedule to ensure that reliability and consistency is maintained during the coding

process. iii. The description and organization of content elements. The categories were used to

describe and organize content elements. This help attain efficiency during sorting

process as well as retrieval of data. iv. Description of the emerging output. The categories were used to describe the

information mined from the data. The unit of analysis used at this level was meant

for data collection acting as input for simulation and modeling.

v. The analysis of coded content. The obtained content was qualitatively analyzed and

synthesized for valid and reliable inferences for simulation and modeling.

77 The network setup and performance parameters considered during content analysis include: the used IP protocol strategy (IPv4, IPv6, transition mechanism, and model), resource oriented (bandwidth) and traffic oriented optimization perspectives (throughput, packet loss, latency, and jitter). The Appendix B shows the Content Analysis Schedule used for data collection.

3.6.2 Interviews

The interviews were administered to offer a relatively higher response rate and clarification of responses undertaken. The interviews were beneficial to gain detailed insights from individual participants who were considered experts in the field of study. It also helped the researcher to understand not only the fact of the subjects but also the meaning of their experience. The interview process aided to find out different point of views, problems, solutions, and attitudes of interviewees within the main theme of this study. The researcher conducted standardized, open ended interviews with experts in charge of IPv6 deployment and network maintenance to find out their different practical experiences. These questions aided the participants to fully express their points of views and experiences. The Appendix

C shows the Interview Schedule used in data collection. The research methodology is indicated in Figure 3.2.

78 Research Design Experimental- simulation Process Flow Research Population Internet Service Providers in Kenya

Sampling Technique Purposive sampling

Sampling Frame All 18 ISPs

Research Tools Content analysis & Interviews

Figure 3. 1: Research methodology (Source: Researcher)

3.7 Quality Control of Research Instruments

There are various definitions of validity and reliability from different researchers. In this study, the understanding of validity and reliability was considered and measured by the idea of trustworthiness to establish confidence in the findings. Multiple perspectives from various sources were compared and tested before the conclusion to strengthen the results and enhance “trustworthiness” (Golafshani, 2003).

3.7.1 Reliability

In this study, reliability refers to the degree to which the research instruments can produce the same result if administered again. Internal consistency reliability estimation was administered to a group of people on one occasion to estimate reliability. This study relies

79 on a variety of sources, which are from technical papers of leading telecommunication companies. Conclusion was drawn in reference to the collected data. All the chosen service providers have carried out IPv6 deployment in their backbone network. All the interviewees are people who are in charge of or involved in IPv6 addresses deployment in their companies. All data sources are listed in references and can be verified. Data collected was analyzed by proper methods in the right procedures so that the study remains stable, reproducible and accurate. The data was analyzed and classified in the same way over a period of time.

3.7.2 Validity

Validity refers to the degree to which questions reflects reality. Internal validity was used to measure the degree to which questions admitted agree with each other and that subject will respond to similar questions in a similar way. It also affects the likelihood of producing false positives and false negatives. Construct Validity was used to ensure that the construct actually measured what was intended to measure rather than other extraneous factors.

Construct validity involved generalizing from the measures to the concept of the measures.

This was assessed by a panel of “experts” familiar with the construct. The experts examined the items and decided what that specific item intended to measure.

3.7.2.1 Surveys

In this section, the method for collecting and validating model data from experts through survey was presented. Survey is a part of the design of this study for assessing the reliability and validity of the IPv6 transition application model developed in this study. Assessment

80 of the application model was planned based on the conceptual framework presented in

Figure 2.24. The conceptual framework comprises of seven independent variables, four dependent variables, and three moderating variables. While the simulations helped in assessing the model using many performance variables, the variables chosen in this model are for assessing the validity of the model with the help of networking experts. Hence, a data collection instrument was designed for conducting a survey and collecting responses on a five-level scale applied to each of the variables. The next Sub-section (3.7.2.2 to

3.7.2.5) presents details about the data collection instrument used in the survey.

3.7.2.2 Data Collection Instrument

The survey was conducted after sharing the application model design and its simulation performance obtained in OPNET Modeler with the networking experts. The survey instrument comprised of multiple choice questions for the seven independent variables, four dependent variables, and three moderating variables of the initial conceptual framework defined at the beginning of this study. The multiple choice questions comprised of a five-level scale for measuring each of the variables. The scale for independent variables was designed as follows:

Level 1: Poor (From 0 to 20% practical validity)

Level 2: Fair (From 21 to 40% practical validity)

Level 3: Good (From 41 to 60% practical validity)

Level 4: Excellent (From 61 to 80% practical validity)

Level 5: Outstanding (81 to 100% practical validity)

81 Such a five-level scale is called a nominal measurement scale (Sekaran, 2003). This type of study is called phenomenography in which, the measures are collected based on individual experiences about a concept, and the collective data from experiences of multiple individuals facilitates inferential analysis (goodness) of the outcome (Saunders,

Lewis, & Thornhill, 2009). The scale for dependent variables and the moderators was designed as the following:

Level 1: Very Low (From 0 to 20%)

Level 2: Low (From 21 to 40%)

Level 3: Medium (From 41 to 60%)

Level 4: High (From 61 to 80%)

Level 5: Very high (81 to 100%)

The instrument designed using the above five-level scale is presented in Appendix D. It may be observed that a question pertaining to every variable has been framed to enable measurement of the variable on the five-level scale. The next Sub-section (3.6.2.2) presents the data collection approach followed in this study.

3.7.2.3 Data Collection Approach

The target respondents were chosen through personal contacts and through LinkedIn, which is a professional networking website. The original plan was to collect data from ISPs operating in Kenya only. However, because of difficulties in achieving a sufficiently sized sample in Kenya alone, data was also collected from networking experts working for Indian

ISPs. Access to them was facilitated though Indian contacts and LinkedIn. The survey questionnaire was shared through internal mailing feature of LinkedIn with 106 networking

82 professionals in Kenya and India. Out of 106, a total number of 78 respondents answered the survey questionnaire. This sample, although not of a significant size, is sufficient for getting professional insight into the Enhanced Network Performance Metrics for transition model created in this study. The data was collated in Excel sheet, the variables were encoded at the top of each column, and finally the data was imported into SPSS Statistical

Package. All the analysis conducted on the data have been accomplished in SPSS.

3.7.2.4 Interpretation of Results

The results in a research should be interpreted after analyzing the outcomes of all the methods followed in a research (Saunders, Lewis, & Thornhill, 2011). This study followed the methods of literature review, modeling and simulations in OPNET Modeler, multiple regression model, and MANOVA. The results of all the four methods have been collectively analyzed, compared, and interpreted methodically for deriving the final conclusions.

3.8 Data Analysis

The collected data was analyzed by both descriptive (feel for data) and inferential

(goodness of data) statistics. Descriptive statistics was used in this context to work out various measures that show the size and shape of a distribution(s) along with the study of measuring relationships between two or more variables.

Inferential statistics were used to infer how likely it is that the findings are the result of nothing more than random chance because it is concerned with the various tests of significance for testing to determine with what validity data can be said to indicate some

83 conclusion(s). It is the basis of inferential analysis that the task of interpretation (i.e., the task of drawing inferences and conclusions) was performed. Both regression analysis and

ANOVA (Analysis of Variance) were used. Regression analysis is an important tool for modelling and analyzing data. It is a form of predictive modelling technique that was used to investigate the relationship between the dependent and independent variables. This technique is of great importance in forecasting, modelling and finding the causal effect relationship between the variables.

In descriptive statistical analysis, the reporting was conducted in SPSS calculating the mean, standard deviation, skewness, and kurtosis (Siegel, 2012). Skewness and kurtosis are indicators of the data distribution. Mean and standard deviation reports are primary for providing the key descriptive information for knowing the data (Siegel, 2012).

In inferential statistical analysis, multiple regression analysis and MANOVA were conducted sequentially. Both these methods provide information about influence of independent variables (called predictors) on the dependent variables (Field, 2009; Siegel,

2012). Multiple regression analysis reveals the extent of linearity relationships between the independent variables and a dependent variable (Field, 2009; Peck & Devore, 2012). This test groups all the independent variables at a time and runs on each dependent variable one by one. Hence, in this study, there are four multiple regression models each for the four dependent variables.

The statistics reported in multiple regression method are R, R Squared, and Adjusted R

Squared. R indicates the correlation of multiple values of the dependent variable with the values of the independent variables (Field, 2009; Peck & Devore, 2012). R squared represents the variation in values of a dependent variable, and Adjusted R squared

84 represents adjustments as a result of change of number of variables. Only the independent variables having linearity relationships with the dependent variable at a confidence interval of 95% and above are retained in the final analysis (Field, 2009). Other independent variables are eliminated.

MANOVA is a cause-effect analysis between multiple independent and multiple dependent variables grouped together in a single model (Field, 2009; Siegel, 2012). Unlike regression analysis, it need not take one dependent variables at a time. Hence, this study resulted in a single MANOVA model. The outcome of MANOVA is the F-statistic, which indicates the extent of variation of a dependent variable because of an independent variable. Only the independent variables having effects on the corresponding dependent variables at a 95% confidence interval are retained for final analysis.

The moderators are tested by including them one by one as independent variables and testing the change in outcomes of the model with respect to the original results without them included (Field, 2009; Peck & Devore, 2012; Siegel, 2012). The moderators were tested in both regression analysis and MANOVA. In this study, the effects of the three moderator variables on the linearity (regression) and causal relationships (MANOVA) are tested in both the methods followed.

3.9 Model Development

This study involves a simulation experiment conducted using the OPNET++. This simulator was chosen as it is considered as highly efficient simulation software and was appropriate in reaching the goal of the experiment. It also includes most of the network technology such as routers and switches, as well as other equipment such as the filters,

85 which were considered important in the analysis of traffic. The experiment consists of the following stages: the network model creation, statistical analysis, simulation to obtain results, the results analysis, discussion and comparison to each other.

3.9.1 Model Design and Development

This study was carried out to develop a model that delivers an Enhanced Network

Performance for transition from Ipv4 to IPv6 network that can be adopted by service providers, network administrators and network architects to improve overall network performance. This was in light of the limited number of models, and immature IPv6 transition mechanisms. The design was based on the transition mechanism and configuration attributes (physical connectivity, addressing plan, routing plan, service plan, network convergence, and load balancing).

3.9.2 Model Testing and Validation

The most important aspect in network simulation process is to ensure a model is credible and represents reality. If this is not guaranteed, then model lacks real value and the outcome can’t be used to answer desired questions (Sargent, 2004). Validation is the process of determining the real-world system being studied is accurately represented by the simulation model. Not only does this process provide assurance that the conceptual approach is correct, it establishes an acceptable level of confidence in the conclusions drawn from running the simulation and provides insight as to the true operating characteristics of the modeled system. This confidence, called face validity, is important to both developer and model user.

86 In this study the validation process begun during the initial stages of the simulation project and continued throughout the simulation process. Simulation inputs were examined and validated. In addition to the analysis of model inputs, outputs were also validated. This is often believed to be a more crucial form of validation. If the model's output closely represents expected values for the real-world system, a sense of confidence in the model’s results is developed. The data collected from actual system operation were used as a benchmark for the model. Therefore, comparison with data from similar systems and experts was used. The validation process was conducted by experts experienced in the subject matter, i.e., design, use, and assessment of IPv6 networks.

3.10 Ethical Issues

The information gathered from participants remained confidential. This includes the participants as well as the information gathered. The participation in the study was voluntary and in line with the core purpose of study. This was accomplished by shading more light on the importance of the study in building a sustainable future. There was absolutely no harm to respondents taking part in the study. The participants were urged to be free and comfortable in the provision of responses.

3.11 Summary

This chapter has outlined the research paradigm, research methodologies, strategies and design used in the study, including procedures, participants, data collection tools, analysis methods, and data credibility issues. The research design for this study was a descriptive and inferential study. It also described the several stages involved in the design and

87 development processes of the research in this study. The next chapter provides the design principles, evaluation instruments, and then the pedagogical model for the study that helped to translate the philosophy into actual practice. In conclusion, it may be stated that the research design and related methodologies were developed with the aim of obtaining reliable and valid data to develop an Enhanced Network Performance Metrics for transition from IPv4 to IPv6 networks. Ultimately, this would help current and prospective Internet

Service Providers (ISPs) to deal with the increased demands caused by the depletion of the pool of IP addresses and transition challenges.

88 CHAPTER FOUR

MODELLING AND SIMULATION RESULTS

4.1 Introduction

This chapter presents modeling and simulation of the IPv6 transition scenarios collected from the ISPs through Content Analysis and Interviews. According to the Communication

Authority of Kenya (CAK) database, there is an existence of a variety of Internet Service

Providers in Kenya for clients to subscribe. As a result, it is cumbersome for clients to identify and settle on the most suitable ISP to address its needs with this kind of diversity.

It is worth mentioning that most businesses now run with the help of the internet, without which they will crumple. In this study, it was helpful to take into consideration an array of factors which were not limited to the cost. Regardless of the types of internet service providers, the following factors were beneficial in choosing the 18 ISPs.

i. Internet reliability and speed

ii. Additional services and bundled resources iii. Internet security solutions iv. Customer support services

The first research question (RQ) “What are the performance degradations associated with transition mechanisms for transition from IPv4 to IPv6 networks?” is presented in Section 4.2 and the second research question (RQ) “How do mapping of configuration attributes to transition mechanisms affect performance degradation from IPv4 to

IPv6 networks?” presented in Section 4.3. The output of simulation for the three model designs (dual stack, IP tunneling, and network address translation) are presented and analyzed in Section 4.4.

89 4.2 Transition Mechanisms for Transiting from IPv4: Content Analysis and

Interview Results

In the recent past, multiple studies have been conducted on performance comparisons between the IPv6 transition schemes. First and foremost, the planning phase was carried.

Secondly, the adoption of the criteria used for primary studies selection, study standard evaluation and required data extraction, mining, and synthetization. Lastly, the final report was written, reviewed and conclusion drawn from the findings.

The research question (RQ) “What are the performance degradations associated with transition mechanisms for transition from IPv4 to IPv6 networks?” purpose to gather key studies to investigate and analyze all subjects related to IPv4/IPv6 network transition performance degradation. The exploration process for preceding and associated studies on the research topic on a variety of guiding principles that can be condensed in the following:

Research findings in databases with regard to the subject matter under investigation; obtaining the technical documentation in full text; selection of technical print derived from factual and precise results. The searching keywords included: IPv4/IPv6 transition mechanisms performance comparisons; Performance analysis of various IPv4/IPv6 transition mechanisms; Performance evaluation of IPv4 vs IPv6 transition techniques; and Performance investigation of IPv4/IPv6 transition Mechanisms.

4.2.1 Content Analysis Results

The Request for Comments (RFCs) were considered for technical data, facts and statistics.

RFCs is a piece of written matter documentary system invented in 1969 by Steve Crocken to keep the record as well as improve technology being used on the ARPAnet. An RFC

90 defines a new technology, research, application or describes existing research and applications on networking technology. The TCP/IP stack was established by the RFC method of development. In this study, the researcher consulted RFCs for data on technical issues. RFCs are the most updated and trustable papers on networking technology.

Table 4. 1: Summary of collected data from content analysis for RFCs (Source: Researcher) List of Author Research Context and Status RFCs Methodology RFC 1933 R. Gilligan, E. Transition Mechanisms Proposed Obsoleted by Nordmark. April 1996. for IPv6 Hosts and Standard RFC 2893) Routers. RFC 2893 R. Gilligan, E. Transition Mechanisms Proposed (Obsoletes Nordmark. August for IPv6 Hosts and Standard RFC 1933) 2000. Routers. (Obsoleted by RFC 4213) RFC 3056 B. Carpenter, K. Moore. Connection of IPv6 Proposed February 2001. Domains via IPv4 Standard Clouds. RFC 3750 C. Huitema, R. Austein, Unmanaged Networks Informational S. Satapati, R. van der IPv6 Transition Pol. April 2004. Scenarios. RFC 3904 C. Huitema, R. Austein, Evaluation of IPv6 Informational S. Satapati, R. van der Transition Mechanisms Pol. September 2004. for Unmanaged Networks. RFC4029 M. Lind, V. Ksinant, S. Scenarios and Analysis Informational Park, A. Baudot, P. for Introducing IPv6 into Savola. March 2005. ISP Networks. RFC 4038 M-K. Shin, Ed., Y-G. Application Aspects of Informational Hong,J. Hagino, P. IPv6 Transition. Savola, E. M. Castro. March 2005. RFC 4057 J.Bound, Ed.. June 2005. IPv6 Enterprise Network Informational Scenarios RFC 4213 E. Nordmark, R. Basic Transition Proposed Gilligan. October 2005. Mechanisms for IPv6 Standard Hosts and Routers.

91 List of Author Research Context and Status RFCs Methodology RFC 4215 J. Wiljakka, Ed. October Analysis on IPv6 Informational 2005. Transition in Third Generation Partnership Project (3GPP) Networks. RFC 4241 Y. Shirasaki, S. A Model of IPv6/IPv4 Informational Miyakawa, T. Dual Stack Internet Yamasaki, A. Access Service. Takenouchi. December 2005. RFC 4380 C. Huitema. February Teredo: Tunneling IPv6 Proposed 2006. over UDP through Standard Network Address Translations (NATs). RFC 4727 B. Fenner. November Experimental Values in Proposed 2006. IPv4, IPv6, ICMPv4, Standard ICMPv6, UDP, and TCP Headers. RFC 4779 S. Asadullah, A. ISP IPv6 Deployment Informational Ahmed, C. Popoviciu, Scenarios in Broadband P. Savola, J. Palet. Access Networks. January 2007. RFC 4852 J. Bound, Y. Pouffary, IPv6 Enterprise Network Informational S. Klynsma, T. Chown, Analysis - IP Layer 3 D. Green. April 2007. Focus. RFC 5569 R. Despres. January IPv6 Rapid Deployment Informational 2010. on IPv4 Infrastructures (6rd). RFC 6018 F. Baker, W. Harrop, G. IPv4 and IPv6 Greynets. Informational Armitage. September 2010 RFC 6036 B. Carpenter, S. Jiang. Emerging Service Informational October 2010. Provider Scenarios for IPv6 Deployment. RFC 6127 J. Arkko, M. Townsley. IPv4 Run-Out and IPv4- Informational May 2011. IPv6 Co-Existence Scenarios. RFC 6144 F. Baker, X. Li, C. Bao, Framework for Informational K. Yin. April 2011. IPv4/IPv6 Translation. RFC 6180 J. Arkko, F. Baker. May Guidelines for Using Informational 2011. IPv6 Transition

92 List of Author Research Context and Status RFCs Methodology Mechanisms during IPv6 Deployment. RFC 6219 X. Li, C. Bao, M. Chen, The China Education Informational H. Zhang, J. Wu. May and Research Network 2011. (CERNET) IVI Translation Design and Deployment for the IPv4/IPv6 Coexistence and Transition RFC 6343 B. Carpenter. August Advisory Guidelines for Informational 2011. 6to4 Deployment. RFC 6586. J. Arkko, A. Keranen. Experiences from an Informational April 2012. IPv6-Only Network RFC 6589 J. Livingood. April Considerations for Informational 2012. Transitioning Content to IPv6. RFC 6883 B. Carpenter, S. Jiang. IPv6 Guidance for Informational March 2013. Internet Content Providers and Application Service Providers. RFC 6964 F.Templin. May 2013. Operational Guidance Informational for IPv6 Deployment in IPv4 Sites Using the Intra-Site Automatic Tunnel Addressing Protocol (ISATAP). RFC 7040 Y. Cui, J. Wu, P. Wu, Public IPv4-over-IPv6 Informational O. Vautrin, Y. Lee. Access Network. November 2013. RFC 7059 S. Steffann, I. van A Comparison of IPv6- Informational Beijnum, R. van Rein. over-IPv4 Tunnel November 2013. Mechanisms. RFC 7381 K. Chittimaneni, T. Enterprise IPv6 Informational Chown, L. Howard, V. Deployment Guidelines. Kuarsingh, Y. Pouffary, E. Vyncke. October 2014. RFC 8136 B. Carpenter, R. Additional Transition Informational Hinden. 1 April 2017. Functionality for IPv6.

93 List of Author Research Context and Status RFCs Methodology RFC 8219 M. Georgescu, L. Benchmarking Informational Pislaru, G. Lencse. Methodology for IPv6 August 2017. Transition Technologies. RFC 8250 N. Elkins, R. Hamilton, IPv6 Performance and Proposed M. Ackermann. Diagnostic Metrics Standard September 2017. (PDM) Destination Option.

In addition, attempts were made to trace references cited in published journal articles on networking technology as technical data in this study. After careful screening of the articles, published studies were found that are directly pertained to the transition of IPv4 to

IPv6 networks. This was considered to obtain more accurate results from the largest and most popular online databases and search engines stipulated in Table 4.2.

Table 4. 2: Electronic databases used in the search process (Source: Researcher) Database URL Science Direct http://www.sciencedirect.com Scopus http://www.scopus.com ACM Digital Library http://dl.acm.org IEEEXplore http://ieeexplore.ieee.org Research Gate http://www.researchgate.net

Additionally, a review of the recent published articles is presented in Table 4.3

Table 4. 3: Details of research studies, research context and methodology, and findings on performance comparisons of IPv6 transition schemes (Source: Researcher) Research Context Mechanisms Findings Authors and Methodology Khadiri, Performance Dual stack, The performance in terms Labouidya, Analysis of Video manual of delay, delay variation, Elkamoun, & Conferencing over tunnel, and the and packet loss in the case Hilal (2018) Various IPv4/IPv6 6to4 automatic of real-time application of Transition tunnel video conferencing was

94 Research Context Mechanisms Findings Authors and Methodology Mechanisms using studied. The dual stack OPNET Modeler mechanism gave better simulator. performance than the tunneling mechanisms (manual tunnel and 6to4 automatic tunnel). That is due to encapsulation and decapsulation processes in the tunnelling mechanisms whereas, in the dual stack, both protocols work simultaneously without involving neither encapsulation nor decapsulation. For the comparison between the protocols (IPv4 and IPv6), IPv4 was more efficient than IPv6. This difference is due to the IPv6 header length, which is higher than the one of IPv4. Khannah & The research by Dual stack, Dual stack performed best Alsadeh (2017) Khannah & manual 6to4 in all the applications and Alsadeh (2017) tunneling, automated 6to4 tunneling has similar setup to automated performed second to dual this research 6to4 tunneling. stack. Manual 6to4 except that the tunneling performed the HTTP, E-Mail, DB worst in voice jitters and Query, and VoIP MOS value. applications were studied for comparing the performances of dual stack, manual 6to4 tunneling, and automated 6to4 tunneling. Hossain, Podder, Performance Dual Stack, If latency, throughput and Jahan, & Analysis of Three Tunneling and packet loss are considered Hussain. (2016) Transition Translation then tunneling method is Mechanisms mechanisms the best choice while the between IPv6 NAT-PT is the worst. But Network and IPv4 the tunneling method has

95 Research Context Mechanisms Findings Authors and Methodology Network: Dual some security issues that Stack, will be solved by IPsec (IP Tunneling and security). So, our Translation recommendation is to use tunneling mode with IPSec for the transition purpose. Ahmed, Mustafa, Performance IPv4, IPv6 and Throughput: IPv6< & Ibrahim Evaluation of manual 6to4tunnel

96 Research Context Mechanisms Findings Authors and Methodology showed less jitter than IPv4 protocol Aazam & Huh In a cloud Teredo, ISATAP was found to be (2014) computing ISATAP, 6to4 comparatively better than virtualization tunneling 6to4 and Teredo in environment, three throughput, end-to-end types of tunnels packet delay, round trip were configured collision delay, tunneling using Teredo, overhead, tunnel set up ISATAP, and 6to4 times, and DNS query and the means of delays. However, ISATAP throughputs, was found comparatively means and poorer than 6to4 tunneling standard and Teredo in VoIP jitters. deviations of voice 6to4 tunnel was found to be over IP jitters, better than Teredo in all means of end-to- variables except VoIP jitters end packet delay, in which, Teredo has the mean of round trip best performance. In collision delay general, 6to4 tunneling was (Ping process), found to be having mean of tunneling sustained performance in all overhead, mean of the performance variables. tunnel set up times, and mean of DNS query delays were studied. Chuangchunsong In this research, a 6to4 tunneling This research found highest et al. (2014) scenario was performance and reliability configured in by NAT centralisation. which, the clients However, NAT cannot be on IPv4 needed to preferred for high density connect to servers communications as too on IPv4 through a many IPv4 addresses will cloud service be needed (one each provider on IPv6 dedicated for a running only. Three session). Hence, this configurations research recommended 6to4 were studied: dual tunneling that appeared as stack at the client second to NAT and server ends, centralisation in 6to4 tunnels performance and reliability. crossing the cloud service provider,

97 Research Context Mechanisms Findings Authors and Methodology NAT centralisation and NAT distributions crossing the cloud service provider. The three scenarios were modelled in OPNET Modeler. Albkerat & Issac Analysis of IPv6 Dual-Stack, The experiment was (2014) Transition Tunnel and executed using OPNET Technologies Translation Modeler to simulate mechanisms throughput, latency, queuing delay, and TCP delay. The Dual-Stack found less delay with TCP, but with 6to4 and manual the delay is higher. IPv6 has higher throughput. The 6to4 and manual strategies required manual configurations to detect the source, and the manual tunnel is required to have the destination detected in order to build the point to point mechanism. Yagoub & Comparison IPv4 and IPv6 Evaluate and compare the Mustafa (2014) Throughput Networks performance of IPv4 and performance IPv6, using OPNET. The comparison drive is to assess the basic between IPv4 and productivity, and packet using OPNET loss, a delay, jitter, and the simulator use of methods based on simulative and analytical network addresses in IPv4/ IPv6. Yagoub, Evaluation and Dual-Stack, Packet loss, latency and Mustafa, & Comparisons of Tunneling and Response Time were Hamied (2014) Migration NAT-PT measured. It was Techniques from mechanisms established that the average IPv4 To IPv6 response time in the tunnel Using GNS3 is equal to 28.5 ms and in Simulator and the Dual Stack is 283 ms.

98 Research Context Mechanisms Findings Authors and Methodology Solarwinds As far as NAT-PT an program average response time of 800 ms. The higher average response time resulted in higher latency. There is higher latency in NAT-PT. it was concluded that from the simulation of these three techniques, the tunnelling technique is the best in terms of latency, packet loss, and RRT. Savita & Comparison Dual stack, Dual stack is easy to Monalisa (2013) analysis of various tunneling implement but network transition mechanisms devices must support both mechanisms from the protocols (IPv4/IPv6) IPv4 to IPv6 and it can only be used to send packets between IPv4 networks or IPv6 networks, an IPv4 device cannot communicate to the IPv6 device and vice versa. Because of the inclusion of both protocols in dual stack devices, the size of the routing table increased considerably resulting in longer processing time and delays of the packet. In contrast, tunneling transition strategy is a better choice in case of the devices which do not support IPv6 protocol. The drawback of tunneling is that packet size increases 20 bytes in the header field of each IPv4 packet resulting in complicated troubleshooting. Ali. (2013) Comparison study IPv4 and IPv6 There will not be one between IPv4 & Networks special day on which IPv4 IPv6. will be turned off and IPv6 turned on because the two

99 Research Context Mechanisms Findings Authors and Methodology protocols can’t coexist without any problems. Narayan & Comparing 6to4 tunneling The TCP jitter through 6to4 Tauch (2010) performance of tunnels was found as stable 6to4 tunneling and almost identical in both scheme of IPv6 the operating systems for all transition between packet sizes. However, both Windows 2003 the operating systems SP2 and Windows reflected very high jitters 2008 SP1 servers through 6to4 tunnels for by testing small packet sizes that throughput, jitter reduced sharply for medium and average packet packet sizes and then rose network delay for gradually for large packet both TCP and sizes. In UDP the jitters UDP traffic types were small and almost (configured on stable for small packet arbitrary ports). sizes. However, UDP jitter values increased gradually in both operating systems for low and medium sized packets and returned slightly lower values in Windows 2003 SP2 as compared with those in Windows 2008 SP1 at larger packet sizes. The TCP average packet network delay through 6to4 tunnel in Windows 2008 SP1 was very high at about 1100 milliseconds while the same in Windows 2003 SP2 was found as close to zero at all packet sizes. The UDP average packet network delay through 6to4 tunnel in Windows 2008 SP1 was quite high between 200 and 600 milliseconds for smaller packet sizes, but it later settled between 50 and 150 milliseconds for large packet sizes. The TCP

100 Research Context Mechanisms Findings Authors and Methodology average packet network delay through 6to4 tunnel in Windows 2003 SP2 was almost constant, varying between 20 and 25 milliseconds. The TCP and UDP throughputs through 6to4 tunnels were found as exactly identical in both the operating systems. The TCP throughput varied from 40 to 70 Mbps for small packet sizes and 70 to 90 Mbps for medium to large packet sizes in both the servers. However, for small packet sizes UDP had a higher variation in throughput from 30 to 70 milliseconds in both the servers. Narayan & Comparing 6to4 tunneling The TCP jitter through 6to4 Tauch (2010a) performance of tunnels was found almost 6to4 tunneling identical in both the scheme of IPv6 operating systems for all transition between packet sizes. However, both Linux Fedora 9.10 the operating systems and Linux Ubuntu reflected very high jitters 11.0 servers by through 6to4 tunnels for testing throughput, small packet sizes that jitter and average reduced sharply for medium packet network packet sizes and then rose delay for both TCP gradually for large packet and UDP traffic sizes. In UDP, the jitter was types (configured found to be very high in on arbitrary ports). Fedora 9.10 for small packet sizes but settled at comparable values with those in Ubuntu 11.0 for larger packet sizes. Both the operating systems returned an increasing trend of UDP jitters through 6to4 tunnels for large packet sizes.

101 Research Context Mechanisms Findings Authors and Methodology The TCP average packet network delay through 6to4 tunnels was found as close to zero at all packet sizes in both the operating systems. The UDP average packet network delay in Fedora 9.10 6to4 tunnel was quite high between 200 and 300 milliseconds for all packet sizes. The TCP average packet network delay through 6to4 tunnel in Ubuntu 11.0 was found as varying between 0 and 50 milliseconds. The TCP and UDP throughputs through 6to4 tunnels were found as exactly identical in both the operating systems The TCP throughput varied from 40 to 70 Mbps for small packet sizes and 70 to 90 Mbps for medium to large packet sizes in both the servers. However, for small packet sizes UDP had a higher variation in throughput from 20 to 70 milliseconds in both the servers.

Before designing the original application for IPv6 transition in this study, a brief review of these recent studies is presented in Table 4.4 with regard to tunneling transition scheme.

102

Table 4. 4: Details of research studies, research context and methodology, and findings on performance tunneling transition scheme (Source: Researcher) Research Context and Mechanism Findings Authors Methodology s Kumar Comparing Dual stack, Dual stack returned the highest et al. performances of dual 6to4 latency compared with tunneling, (2016) stack, 6to4 tunneling, tunneling, and NAT schemes. The latencies of and NAT schemes of NAT 6to4 tunneling and NAT were found IPv6 transition by to be comparable. modelling them in Wireshark tool and testing round trip collision delay (latency) using PING and Trace Route processes Naraya Comparing 6to4 The TCP jitter through 6to4 tunnels n & performance of 6to4 tunneling was found as stable and almost Tauch tunneling scheme of identical in both the operating (2010) IPv6 transition between systems for all packet sizes. Windows 2003 SP2 and However, both the operating Windows 2008 SP1 systems reflected very high jitters servers by testing through 6to4 tunnels for small throughput, jitter and packet sizes that reduced sharply for average packet network medium packet sizes and then rose delay for both TCP and gradually for large packet sizes. In UDP traffic types UDP the jitters were small and (configured on almost stable for small packet sizes. arbitrary ports). However, UDP jitter values increased gradually in both operating systems for low and medium sized packets and returned slightly lower values in Windows 2003 SP2 as compared with those in Windows 2008 SP1 at larger packet sizes. The TCP average packet network delay through 6to4 tunnel in Windows 2008 SP1 was very high at about 1100 milliseconds while

103 Research Context and Mechanism Findings Authors Methodology s the same in Windows 2003 SP2 was found as close to zero at all packet sizes. The UDP average packet network delay through 6to4 tunnel in Windows 2008 SP1 was quite high between 200 and 600 milliseconds for smaller packet sizes, but it later settled between 50 and 150 milliseconds for large packet sizes. The TCP average packet network delay through 6to4 tunnel in Windows 2003 SP2 was almost constant, varying between 20 and 25 milliseconds. The TCP and UDP throughputs through 6to4 tunnels were found as exactly identical in both the operating systems. The TCP throughput varied from 40 to 70 Mbps for small packet sizes and 70 to 90 Mbps for medium to large packet sizes in both the servers. However, for small packet sizes UDP had a higher variation in throughput from 30 to 70 milliseconds in both the servers. Naraya Comparing 6to4 The TCP jitter through 6to4 tunnels n & performance of 6to4 tunneling was found almost identical in both Tauch tunneling scheme of the operating systems for all packet (2010a) IPv6 transition between sizes. However, both the operating Linux Fedora 9.10 and systems reflected very high jitters Linux Ubuntu 11.0 through 6to4 tunnels for small servers by testing packet sizes that reduced sharply for throughput, jitter and medium packet sizes and then rose average packet network gradually for large packet sizes. In delay for both TCP and UDP, the jitter was found to be very UDP traffic types high in Fedora 9.10 for small packet (configured on sizes but settled at comparable arbitrary ports). values with those in Ubuntu 11.0 for larger packet sizes. Both the operating systems returned an increasing trend of UDP jitters through 6to4 tunnels for large packet sizes.

104 Research Context and Mechanism Findings Authors Methodology s The TCP average packet network delay through 6to4 tunnels was found as close to zero at all packet sizes in both the operating systems. The UDP average packet network delay in Fedora 9.10 6to4 tunnel was quite high between 200 and 300 milliseconds for all packet sizes. The TCP average packet network delay through 6to4 tunnel in Ubuntu 11.0 was found as varying between 0 and 50 milliseconds. The TCP and UDP throughputs through 6to4 tunnels were found as exactly identical in both the operating systems The TCP throughput varied from 40 to 70 Mbps for small packet sizes and 70 to 90 Mbps for medium to large packet sizes in both the servers. However, for small packet sizes UDP had a higher variation in throughput from 20 to 70 milliseconds in both the servers.

Aazam In a cloud computing Teredo, ISATAP was found to be & Huh virtualization ISATAP, comparatively better than 6to4 and (2014) environment, three 6to4 Teredo in throughput, end-to-end types of tunnels were tunneling packet delay, round trip collision configured using delay, tunneling overhead, tunnel Teredo, ISATAP, and set up times, and DNS query delays. 6to4 and the means of However, ISATAP was found throughputs, means and comparatively poorer than 6to4 standard deviations of tunneling and Teredo in VoIP voice over IP jitters, jitters. 6to4 tunnel was found to be means of end-to-end better than Teredo in all variables packet delay, mean of except VoIP jitters in which, Teredo round trip collision has the best performance. In delay (Ping process), general, 6to4 tunneling was found mean of tunneling to be having sustained performance overhead, mean of in all the performance variables. tunnel set up times, and mean of DNS query delays were studied.

105 Research Context and Mechanism Findings Authors Methodology s Chuang In this research, a 6to4 This research found highest chunson scenario was tunneling performance and reliability by NAT g et al. configured in which, centralisation. However, NAT (2014) the clients on IPv4 cannot be preferred for high density needed to connect to communications as too many IPv4 servers on IPv4 through addresses will be needed (one each a cloud service provider dedicated for a running session). on IPv6 only. Three Hence, this research recommended configurations were 6to4 tunneling that appeared as studied: dual stack at second to NAT centralisation in the client and server performance and reliability. ends, 6to4 tunnels crossing the cloud service provider, NAT centralisation and NAT distributions crossing the cloud service provider. The three scenarios were modelled in OPNET Modeler. Khanna The research by Dual stack, Dual stack performed best in all the h & Khannah & Alsadeh manual 6to4 applications and automated 6to4 Alsadeh (2017) has similar setup tunneling, tunneling performed second to dual (2017) to this research except automated stack. Manual 6to4 tunneling that the HTTP, E-Mail, 6to4 performed the worst in voice jitters DB Query, and VoIP tunneling. and MOS value. applications were studied for comparing the performances of dual stack, manual 6to4 tunneling, and automated 6to4 tunneling.

The comparison in Table 4.4 reflects that IPv6 transition performance may vary based on many additional factors based on operating systems and their versions. The factors found in the studies compared in Table 4.4 are based on tunneling mechanisms, and also based on increase in density of customers. Perhaps, many more factors may be found in the future studies. Hence, the argument in previous paragraph against generalization and empiricism

106 may hold to be true. There should not be any bias towards a particular IPv6 transition mechanism. Instead, there should be more design principles than merely evaluating the performance comparisons between the IPv6 transition mechanisms.

4.2.2 Interview Results

The interview was administered to the respective network technical teams for the ISPs running both IPv4 and IPv6 platforms. The qualitative content analysis approach was used since almost all ISPs were unwilling to provide content with regard to network printouts, performance reports and system logs for evaluation by the researcher. As a result, only descriptive/textual analysis was achieved due to its interpretive nature and failure to provide performance reports and system logs by ISPs.

“We are in a competitive market and due to business and security reasons some information may not be made available to the third party, it is against the information policy. For instance, before subscribing to an ISP it is always a good practice to ask whether the internet is fairly shared or dedicated. This concept has been theoretically stated to the end user with minimal audit mechanisms especially during peak time” (Source: a network expert participating in the interview of this study). The data was collected and summarized as depicted in Table 4.5.

107 Table 4. 5: Summary of collected data from content analysis and interview from ISPs Internet Service Internet Protocol Resource Traffic Oriented Providers Strategy Oriented Optimization

Optimization

Tool

IP IPv6

Jitter

Latency

Transition

Mechanism

Packet Loss Packet Throughput Zuku ✓ ✓ Dual Stack  - - - - Safaricom ✓ ✓ Dual Stack,  - - - - IP Tunneling Airtel ✓ ✓ IP Tunneling  - - - - Orange ✓ ✓ IP Tunneling  - - - - Faiba Internet ✓ ✓ Dual Stack  - - - - Access Kenya Group ✓ ✓ IP Tunneling  - - - - Acevilla Development ✓ ✓ NAT  - - - - Co Ltd Africa 2000 Network ✓ ✓ Dual Stack  - - - - African Regional ✓ ✓ IP Tunneling  - - - - Centre for Computing KENET ✓ ✓ Dual Stack  - - - - Alphanet ✓ ✓ NAT  - - - - Communications Ltd Altech Swift Global ✓ ✓ Dual Stack  - - - - Liquid Telkom ✓ ✓ Dual Stack  - - - - Bandwidth and Cloud ✓ ✓ NAT  - - - - Services Kenya Web Ltd ✓ ✓ Dual Stack  - - - - Google Kenya Ltd ✓ ✓ IP Tunneling  - - - - Jamii ✓ ✓ IP Tunneling  - - - - Telecommunications Ltd Dellsat Network Co. ✓ ✓ NAT  - - - - Ltd

Based on the data collected from the listed ISPs, it is evident that there are three dominant

IPv6 transition mechanisms deployed in the industry as illustrated in Table 4.5. These are dual stack, IP tunneling, and network address translation. In addition, other findings by the researcher included:

108 i. The CIDR approach experiences challenges as the number of connected nodes

increases. With more connected nodes, most of the enterprises change and/or

integrate ISPs and as a result, global routing tables become large, inefficient and

unmanageable. The cost associated with changing all IPv4 addresses of the

connected nodes to match the new network identifier assigned by the new ISP is

extremely costly. Therefore, the problem with this implementation is that the

routing table execution has similar cost implications as the earlier class-full routing.

ii. The NAT implementation model supports asymmetric data access. The

fundamental access to the global Internet is only from the private network and it is

evident the model breaks consistently. The NAT principle does not guarantee

security since most enterprise security breaches take place inside the enterprise

network. iii. The end-to-end principle of the internet is a key consideration for Internet

connectivity architecture. However, the asymmetric data access interferes with this

principle and failure to consistently adhere to the Internet architecture has already

shown user-level problems. For instance, there are several applications that depend

on IP addresses, such as FTP and VoIP, that are broken down by NAT. iv. The principle of asymmetric data access is supported by HTTP protocol in charge

of surfing the World Wide Web. Although NATs and firewalls interfere with IPv4

addressing, they try to minimize damage to traffic traveling over IPv4 port 80,

which is the HTTP unsecure protocol port.

v. The NAT platform enables several clients to jointly use the allocated IP address for

internet connectivity. One critical concern with multiple-client sharing is that there

109 are about 64000 IP port numbers available for a single address. Most internet

browsers utilize approximately four sessions each. Subsequently, peer-to-peer

applications utilize approximately four to ten sessions each while mail utilize

approximately two- to five- sessions each, etc. Practically, the low artificial

limitation created by NAT has negatively affected popular applications such as

Google Maps to fail upon implementation.

4.3 Map of the various configuration attributes from IPv4 to IPv6 Networks:

Modeling Designs in OPNET Modeler

This section attempts to answer the research question (RQ) “How do mapping of configuration attributes to transition mechanisms affect performance degradation from IPv4 to IPv6 networks?”. As a result, it aims to present modeling and simulation findings of the existing three IPv6 transition scenarios of dual stack, IP tunneling, and network address translation in OPNET Modeler version 17.5 provided by Riverbed

Technologies. The justification for selecting OPNET for modeling and simulations was presented in Section 3.2 (Research Design). The modeling reports are presented in Section

4.3 and simulation results are presented in Section 4.4. The simulations have been conducted by running three types of traffic profiles in OPNET. The performances of the three IPv6 transition scenarios have been compared to assess the design evolution of an optimum IPv6 transition design. Section 4.4 and chapter 5 present the modeling and simulations application for optimal IPv6 transition design. The findings of all the simulations are analyzed and summarized in Section 4.6 at the end of the chapter. Figure

4.1 shows the Simulation Methodology.

110

Figure 4. 1: Simulation methodology (Source: Researcher)

The models have been created using the object canvas interface of OPNET Modeler. The object canvas was used for creating nodes, links, protocols, applications, runtimes, traffic shaping, application demands, and all such objects applied in designing a virtual network model. The objects are pulled from the internal objects library of OPNET that is accessible through the OPNET’s object palette. The core model designed in OPNET modeler is presented in Figure 4.2. This model represents an ISP network deployed with four Cisco

7507 layer-4 routing switches, four servers for running the application services, and six client LANs having 10 subscribers each. Each client LAN is connecting to the ISP network over a 1000BaseX link thus allocating 100 Mbps per client on the LAN. The inter-switch links and the links to the four servers are also 1000BaseX links. In real ISP networks, these links may be 10G Ether channels or ATM links because thousands of clients connect to the

111 ISP network for accessing the Internet-enabled services. This model has only 60 clients and hence 1000BaseX links are sufficient for meeting the objectives of this study. The IP attributes object has been added for enabling compressions such that the network services may be improved. An ISP network uses IP compressions for optimizing capacity utilization

(Source: a network expert participating in the survey of this study).

Figure 4. 2: The design of the model for IPv6 transition (Source: Researcher’s OPNET Model)

The configurations in the IP attributes object are presented in Figure 4.3. By default, there are six compression schemes configured in OPNET. In this model, the per-interface compression and TCP/IP header compression schemes have been chosen, as per inputs provided by a survey participant network expert in this study. The compression parameters have been left at OPNET’s default.

112

Figure 4. 3: IP compression schemes (Source: Researcher’s OPNET Model)

The next step was configuration of the applications, as shown in Figure 4.4. Three types of applications were configured in the model i.e. Heavy duty database querying (indicated as

High Load in OPNET), voice application with IP Telephony and silence suppressed and high resolution video conferencing. OPNET comprises of internal configurations for traffic interactions, packet sizes, inter-arrival times, sequencing, flow profiling (like linear, exponential, and logarithmic), and many other attributes for each of these application definitions. These traffic configurations have been retained for simulations in the three

IPv6 transition designs.

113

Figure 4. 4: Application traffic configurations for the three IPv6 transition designs (Source: Researcher’s OPNET Model)

The application traffic configurations were followed by application runtime profiles configurations for the three application definitions as indicated in Figure 4.5.

114

Figure 4. 5: Application runtime profile configurations for the three IPv6 transition designs (Source: Researcher’s OPNET Model)

The repetition pattern of the three applications was set at “concurrent”. In addition, the operation mode of the profile runtime was configured as “simultaneous” and “end of simulation”. These settings ensured that the applications shall begin simultaneously (no

115 time lags between their starting), run concurrently and continuously till the simulation is terminated. However, a delay of range 100 to 110 seconds for starting of the profile from the time of trigger of simulation was configured to ensure that all routing protocols’ replications and network broadcasts are completed before the applications begin. This setting ensured that the network was fully operational before the profile started running.

With these basic settings, the network was made ready to be configured for the three IPv6 transitions. The runtime profile “ISP Applications” is attached to the six client LANs and the four servers. The configurations for the three IPv6 transitions are explained in Sub- sections 4.3.1, 4.3.2, and 4.3.3.

4.3.1 Modeling Design of Dual Stack IPv6 Transition

In this design, Ethernet interfaces on all network devices need to be dual compatible in terms of IP addressing scheme. The IPv4 addresses may be confined only to the servers and the core switches connecting them. The end switches and all the client nodes (PCs or mobile devices) may be configured with IPv6 thus ensuring freeing of a massive address space of IPv4. This is the ideal scenario for future. However, in the current scenario faced by ISPs, clients may be both IPv4 and IPv6 enabled and servers may be deployed on both

IPv4 and IPv6.

To replicate the current readiness of an ISP, the core and edge switches are configured with

IPv4 as well as IPv6. However, keeping in mind the future, the dual stack model has been configured with clients having IPv6 addresses only and servers having IPv4 addresses only.

Figure 4.6 shows the IPv4 assignment of SVR_1 server. The IPv6 address assignment on this server is configured as “not active”. All the four servers have similar settings.

116

Figure 4. 6: Servers IP addressing showing IPv4 (only) assignment for dual stack (Source: Researcher’s OPNET Model)

Figure 4.7 shows the IPv6 assignment of Client_LAN_2 clients’ LAN. The IPv4 address assignment on this server is configured as “auto assigned” but no IP address is allocated.

The entire client side comprising six client LANs have similar settings.

117

Figure 4. 7: Client LANs IP addressing showing IPv6 (Only) assignment for dual stack (Source: Researcher’s OPNET Model)

Figure 4.8 presents the IPv4 address assignment on SW_1 switch on its interface IF1.

Figure 4.9 presents the IPv6 address assignment on SW_1 switch on the same interface.

118

Figure 4. 8: Switches IP addressing showing IPv4 assignment for dual stack (Source: Researcher’s OPNET Model)

119

Figure 4. 9: Switches IP addressing showing IPv6 assignment for dual stack (Source: Researcher’s OPNET Model)

This is because all the four switches were configured in dual stack mode and assigned both

IP address versions. In this configuration, the switched LAN of the ISP can support both clients and servers with either IPv4 or IPv6 assignments. The list of all the devices, their interfaces, their IP addressing schemes and IP address allocations, and the name of peering devices are presented in Table 4.6. The client LANs are configured with one interface each connecting to the ISP LAN. These interfaces are configured with IPv6 addresses. They may be viewed as public IPv6 address assignments to each client LAN such that the traffic coming from the connected computers shall inherit the respective public IPv6 address to gain access to the Internet servers. The ISP has four Internet servers configured on IPv4.

120 Hence, the task of connecting the client LANs with IPv6 addressing to the servers with

IPv4 addressing is of the four switches configured in dual stack mode.

Table 4. 6: IP address assignments in the dual stack implementation (Source: Researcher’s model in OPNET) S. Device Interface IP IP Address Allocated Connecting No. Name Addressing to Device Scheme Name 1 Client IF0 IPv6 2005:0:0:C:0:0:0:1 SW_1 _LAN_1 2 Client IF0 IPv4 Not allocated SW_1 _LAN_1 3 Client IF0 IPv6 2005:0:0:B:0:0:0:1 SW_1 _LAN_2 4 Client IF0 IPv4 Not allocated SW_1 _LAN_2 5 Client IF0 IPv6 2005:0:0:2:0:0:0:2 SW_2 _LAN_3 6 Client IF0 IPv4 Not allocated SW_2 _LAN_3 7 Client IF0 IPv6 2005:0:0:1:0:0:0:2 SW_2 _LAN_4 8 Client IF0 IPv4 Not allocated SW_2 _LAN_4 9 Client IF0 IPv6 2005:0:0:5:0:0:0:2 SW_3 _LAN_5 10 Client IF0 IPv4 Not allocated SW_3 _LAN_5 11 Client IF0 IPv6 2005:0:0:4:0:0:0:2 SW_4 _LAN_6 12 Client IF0 IPv4 Not allocated SW_4 _LAN_6 13 SW_1 IF1 IPv4 192.0.14.2 (with SW_2 default Class C subnet mask) 14 SW_1 IF2 IPv4 192.0.13.2 (with SW_4 default Class C subnet mask) 15 SW_1 IF3 IPv4 192.0.12.1 (with Client default Class C subnet _LAN_1 mask) 16 SW_1 IF4 IPv4 192.0.11.1 (with Client default Class C subnet _LAN_2 mask) 17 SW_1 IF1 IPv6 2005:0:0:E:0:0:0:2 SW_2

121 S. Device Interface IP IP Address Allocated Connecting No. Name Addressing to Device Scheme Name 18 SW_1 IF2 IPv6 2005:0:0:D:0:0:0:2 SW_4 19 SW_1 IF3 IPv6 2005:0:0:D:0:0:0:2 Client _LAN_1 20 SW_1 IF4 IPv6 2005:0:0:B:0:0:0:2 Client _LAN_2 21 SW_2 IF1 IPv4 192.0.2.1 (with default Client Class C subnet mask) _LAN_3 22 SW_2 IF2 IPv4 192.0.1.1 (with default Client Class C subnet mask) _LAN_4 23 SW_2 IF3 IPv4 192.0.14.1 (with SW_1 default Class C subnet mask) 24 SW_2 IF4 IPv4 192.0.3.1 (with default SW_3 Class C subnet mask) 25 SW_2 IF1 IPv6 2005:0:0:2:0:0:0:1 Client _LAN_3 26 SW_2 IF2 IPv6 2005:0:0:1:0:0:0:1 Client _LAN_4 27 SW_2 IF3 IPv6 2005:0:0:E:0:0:0:1 SW_1 28 SW_2 IF4 IPv6 2005:0:0:3:0:0:0:1 SW_3 29 SW_3 IF1 IPv4 192.0.5.1 (with default Client Class C subnet mask) _LAN_5 30 SW_3 IF2 IPv4 192.0.4.1 (with default Client Class C subnet mask) _LAN_6 31 SW_3 IF3 IPv4 192.0.3.2 (with default SW_2 Class C subnet mask) 32 SW_3 IF4 IPv4 192.0.10.1 (with SW_4 default Class C subnet mask) 33 SW_3 IF1 IPv6 2005:0:0:5:0:0:0:1 Client _LAN_5 34 SW_3 IF2 IPv6 2005:0:0:4:0:0:0:1 Client _LAN_6 35 SW_3 IF3 IPv6 2005:0:0:3:0:0:0:2 SW_2 36 SW_3 IF4 IPv6 2005:0:0:A:0:0:0:1 SW_4 37 SW_4 IF1 IPv4 192.0.10.2 (with SW_3 default Class C subnet mask) 38 SW_4 IF2 IPv4 192.0.13.1 (with SW_1 default Class C subnet mask) 39 SW_4 IF3 IPv4 192.0.9.1 (with default SVR_3 Class C subnet mask)

122 S. Device Interface IP IP Address Allocated Connecting No. Name Addressing to Device Scheme Name 40 SW_4 IF4 IPv4 192.0.8.1 (with default SVR_2 Class C subnet mask) 41 SW_4 IF5 IPv4 192.0.7.1 (with default SVR_1 Class C subnet mask) 42 SW_4 IF6 IPv4 192.0.6.1 (with default SVR_4 Class C subnet mask) 43 SW_4 IF1 IPv6 2005:0:0:A:0:0:0:2 SW_3 44 SW_4 IF2 IPv6 2005:0:0:D:0:0:0:1 SW_1 45 SW_4 IF3 IPv6 2005:0:0:9:0:0:0:1 SVR_3 46 SW_4 IF4 IPv6 2005:0:0:8:0:0:0:1 SVR_2 47 SW_4 IF5 IPv6 2005:0:0:7:0:0:0:1 SVR_1 48 SW_4 IF6 IPv6 2005:0:0:6:0:0:0:1 SVR_4 49 SVR_1 IF0 IPv6 Not allocated SW_4 50 SVR_1 IF0 IPv4 192.0.7.2 (with default SW_4 Class C subnet mask) 51 SVR_2 IF0 IPv6 Not allocated SW_4 52 SVR_2 IF0 IPv4 192.0.9.2 (with default SW_4 Class C subnet mask) 53 SVR_3 IF0 IPv6 Not allocated SW_4 54 SVR_3 IF0 IPv4 192.0.8.2 (with default SW_4 Class C subnet mask) 55 SVR_4 IF0 IPv6 Not allocated SW_4 56 SVR_4 IF0 IPv4 192.0.6.2 (with default SW_4 Class C subnet mask)

The simulations were conducted on the dual stack IPv6 transition model by selecting appropriate reports for voice, data, video, TCP, and IP performance. The simulation reports of dual stack design are presented and discussed in Sub-section 4.3.1. The next Sub-section

(4.3.2) presents the design and modeling details of IP tunneling for IPv6 transition.

4.3.2 Modeling Design of IP Tunneling IPv6 Transition

The IP address assignments in the IP tunneling implementation is presented in Table 4.7.

In this design, the Client LANs Client_LAN_1 to Client_LAN_6, and the switches SW_1,

SW_2, and SW_3 are all configured with IPv6 addresses only. Switch SW_4 and the four

123 servers SVR_1 to SVR_4 are all configured with IPv4 addresses only. Hence, tunneling configurations have been configured from SW_1, SW_2, and SW_3 to SW_4 for the six client LANs to communicate with the four servers. For reverse communications from the four servers to the six client LANs, tunnels have been configured from SW_4 to SW_1 to

SW_3 switches.

Table 4. 7: IP address assignments in the IP tunneling implementation (Source: Researcher’s model in OPNET) IP Connecting S. Device Interface Addressing IP Address Allocated to Device No. Name Scheme Name 1 Client IF0 IPv6 2005:0:0:C:0:0:0:2 SW_1 _LAN_1 2 Client IF0 IPv4 Not allocated SW_1 _LAN_1 3 Client IF0 IPv6 2005:0:0:B:0:0:0:2 SW_1 _LAN_2 4 Client IF0 IPv4 Not allocated SW_1 _LAN_2 5 Client IF0 IPv6 2005:0:0:2:0:0:0:2 SW_2 _LAN_3 6 Client IF0 IPv4 Not allocated SW_2 _LAN_3 7 Client IF0 IPv6 2005:0:0:1:0:0:0:2 SW_2 _LAN_4 8 Client IF0 IPv4 Not allocated SW_2 _LAN_4 9 Client IF0 IPv6 2005:0:0:5:0:0:0:2 SW_3 _LAN_5 10 Client IF0 IPv4 Not allocated SW_3 _LAN_5 11 Client IF0 IPv6 2005:0:0:4:0:0:0:2 SW_4 _LAN_6 12 Client IF0 IPv4 Not allocated SW_4 _LAN_6 13 SW_1 IF1 IPv6 2005:0:0:E:0:0:0:1 SW_2 14 SW_1 IF2 IPv6 2005:0:0:D:0:0:0:1 SW_4 15 SW_1 IF3 IPv6 2005:0:0:C:0:0:0:1 Client _LAN_1 16 SW_1 IF4 IPv6 2005:0:0:B:0:0:0:1 Client _LAN_2

124 IP Connecting S. Device Interface Addressing IP Address Allocated to Device No. Name Scheme Name 17 SW_2 IF1 IPv6 2005:0:0:2:0:0:0:1 Client _LAN_3 18 SW_2 IF2 IPv6 2005:0:0:1:0:0:0:1 Client _LAN_4 19 SW_2 IF3 IPv6 2005:0:0:E:0:0:0:2 SW_1 20 SW_2 IF4 IPv6 2005:0:0:3:0:0:0:2 SW_3 21 SW_3 IF1 IPv6 2005:0:0:5:0:0:0:1 Client _LAN_5 22 SW_3 IF2 IPv6 2005:0:0:4:0:0:0:1 Client _LAN_6 23 SW_3 IF3 IPv6 2005:0:0:3:0:0:0:1 SW_2 24 SW_3 IF4 IPv6 2005:0:0:A:0:0:0:1 SW_4 25 SW_4 IF1 IPv4 192.0.10.1 (with SW_3 default Class C subnet mask) 26 SW_4 IF2 IPv4 192.0.13.1 (with SW_1 default Class C subnet mask) 27 SW_4 IF3 IPv4 192.0.9.1 (with default SVR_3 Class C subnet mask) 28 SW_4 IF4 IPv4 192.0.8.1 (with default SVR_2 Class C subnet mask) 29 SW_4 IF5 IPv4 192.0.7.1 (with default SVR_1 Class C subnet mask) 30 SW_4 IF6 IPv4 192.0.6.1 (with default SVR_4 Class C subnet mask) 31 SVR_1 IF0 IPv4 192.0.7.2 (with default SW_4 Class C subnet mask) 32 SVR_1 IF0 IPv6 Not Assigned SW_4 33 SVR_2 IF0 IPv4 192.0.9.2 (with default SW_4 Class C subnet mask) 34 SVR_2 IF0 IPv6 Not Assigned SW_4 35 SVR_3 IF0 IPv4 192.0.8.2 (with default SW_4 Class C subnet mask) 36 SVR_3 IF0 IPv6 Not Assigned SW_4 37 SVR_4 IF0 IPv4 192.0.6.2 (with default SW_4 Class C subnet mask) 38 SVR_4 IF0 IPv6 Not Assigned SW_4 39 SW_1 Tunnel0 IPv6 2005:0:0:C:0:0:0:100 SW_4 Tunnel Interface

125 IP Connecting S. Device Interface Addressing IP Address Allocated to Device No. Name Scheme Name 40 SW_1 Tunnel0 IPv4 192.168.1.1 (with SW_4 Tunnel default Class C subnet mask) 41 SW_3 Tunnel1 IPv6 2005:0:0:C:0:0:0:101 SW_4 Tunnel Interface 42 SW_3 Tunnel1 IPv4 192.168.1.2 (with SW_4 Tunnel default Class C subnet mask) 43 SW_4 Tunnel0 IPv6 2005:0:0:C:0:0:0:102 SW_1 Tunnel Interface 44 SW_4 Tunnel0 IPv4 192.168.1.3 (with SW_1 Tunnel default Class C subnet mask) 45 SW_4 Tunnel 1 IPv6 2005:0:0:C:0:0:0:103 SW_3 Tunnel Interface 46 SW_4 Tunnel1 IPv4 192.168.1.4 (with SW_3 Tunnel default Class C subnet mask)

The tunnels are configured from SW_1 and SW_3 only because they are gateways for accessing the servers through SW_4. Figures 4.9 to 4.15 present the tunnel configurations designed in this mode. Figure 4.10 shows the IPv6 tunnel interface (endpoint of an IP tunnel) created on SW_1 and Figure 38 shows the IPv6 tunnel interface created on SW_3.

The tunnel named “Tunnel0” is initiated from SW_1 and the one named “Tunnel1” is initiated from SW_3. The IPv6 addresses assigned to the tunnel interfaces on these two switches are listed in Table 4.7.

126

Figure 4. 10: Tunnel interface configuration on switch SW_1 (Source: Researcher’s OPNET Model)

Figure 4. 11: Tunnel interface configuration on switch SW_3 (Source: Researcher’s OPNET Model)

127 In Switch SW_4, there are two tunnel interfaces configured for the two tunnels “Tunnel0” and “Tunnel1” as both are terminating at the same switch. Figure 4.12 presents the IPv6 assignments of the tunnel interfaces. These assignments are also listed in Table 4.7.

Loopback interfaces can also be configured as tunnel endpoints.

Figure 4. 12: Tunnel interface configuration on switch SW_4 (Source: Researcher’s OPNET Model)

After configuring the tunnel interfaces, the next step followed is to configure the tunnels.

Figure 4.13 shows the tunnel configuration on SW_1.

128

Figure 4. 13: Tunnel configuration on switch SW_1 (Source: Researcher’s OPNET Model)

A tunnel configuration should have its source and destination points and its own IP address.

The source is the interface of the switch from which, the tunnel is initiating. In SW_1, it is

IF2. The destination is the tunnel interface address on which, the tunnel is intended to terminate. For the tunnel “Tunnel0” initiating from SW_3, the destination tunnel interface

IP address is the same as that configured on SW_4. The tunnel itself may be assigned an

IPv4 or IPv6 address for further access listing. However, it is not mandatory as it will work even without an IP address. In SW_1, the tunnel addressing is chosen as IPv4 and assigned

192.168.1.1. As presented in Figure 4.14, similar configurations have been done for the switch SW_3. The source interface on this switch is IF4 and the destination IPv6 is the tunnel interface IP address for tunnel “Tunnel1” configured in SW_4. The tunnel IP address is assigned as 192.168.1.2. These IP addresses are listed in Table 4.2.

129

Figure 4. 14: Tunnel configuration on switch SW_3 (Source: Researcher’s OPNET Model)

The tunnel mode is selected as IPv6 (6 to 4). The encryption is GRE, which is Cisco’s default. In OPNET, this tunnel mode can ensure IPv6 to IPv4 communications and also the vice versa. In switch SW_4, no tunnel configurations are required if only one-way sessions from the client LANs to the servers are desired. However, if sessions from the servers to the client LANs are desired, then reverse tunnel configurations need to be done on SW_4.

These reverse tunnel configurations in SW_4 for invoking reverse communications through tunnels “Tunnel0” and “Tunnel1” are presented in Figures 4.15 and 4.16 respectively. Such reverse tunnels may not be needed for generic Internet-based communications. However, they are useful in corporate Internet-based communications when the servers also need to initiate sessions to client machines for certain advanced

130 operations, like automated backups, applying security patches, and distribution of new software or applications.

Figure 4. 15: First tunnel configuration on switch SW_4 (Source: Researcher’s OPNET Model)

Figure 4. 16: Second tunnel configuration on switch SW_4 (Source: Researcher’s OPNET Model)

131

In the reverse tunnel configurations, the source for tunnel “Tunnel0” is IF2 while tunnel destination is the tunnel interface IPv6 configuration on SW_1. Further, the source for tunnel “Tunnel1” is IF1 and the tunnel destination is the tunnel interface IPv6 configuration on SW_3. The reverse tunnels have been assigned IPv4 addresses as 192.168.1.3 for

“Tunnel0” and 192.168.1.4 for “Tunnel1”. These IP addresses are listed in Table 4.7. The simulation results for the tunneling configuration of IPv6 transition is presented and discussed in Sub-section 4.3.2.

4.3.3 Modeling Design of Network Address Translation IPv6 Transition

In the third model, the network address translation (NAT) design of IPv6 transition was implemented. The IP address assignments in the NAT design are presented in Table 4.7. A

NAT pool has been added for IPv6 transition through NAT design.

Table 4. 8: IP address assignments in the network address translation implementation (Source: Researcher’s model in OPNET) IP Connecting S. IP Address Device name Interface Addressing to Device No. Allocated Scheme Name 1 Client IF0 IPv6 2005:0:0:C:0:0:0:1 SW_1 _LAN_1 2 Client IF0 IPv4 Not allocated SW_1 _LAN_1 3 Client IF0 IPv6 2005:0:0:B:0:0:0:1 SW_1 _LAN_2 4 Client IF0 IPv4 Not allocated SW_1 _LAN_2 5 Client IF0 IPv6 2005:0:0:2:0:0:0:1 SW_2 _LAN_3 6 Client IF0 IPv4 Not allocated SW_2 _LAN_3 7 Client IF0 IPv6 2005:0:0:1:0:0:0:1 SW_2 _LAN_4

132 IP Connecting S. IP Address Device name Interface Addressing to Device No. Allocated Scheme Name 8 Client IF0 IPv4 Not allocated SW_2 _LAN_4 9 Client IF0 IPv6 2005:0:0:5:0:0:0:1 SW_3 _LAN_5 10 Client IF0 IPv4 Not allocated SW_3 _LAN_5 11 Client IF0 IPv6 2005:0:0:4:0:0:0:1 SW_4 _LAN_6 12 Client IF0 IPv4 Not allocated SW_4 _LAN_6 13 SW_1 IF1 IPv6 2005:0:0:E:0:0:0:1 SW_2 14 SW_1 IF2 IPv6 2005:0:0:D:0:0:0:1 SW_4 15 SW_1 IF3 IPv6 2005:0:0:C:0:0:0:2 Client _LAN_1 16 SW_1 IF4 IPv6 2005:0:0:B:0:0:0:2 Client _LAN_2 17 SW_2 IF1 IPv6 2005:0:0:2:0:0:0:2 Client _LAN_3 18 SW_2 IF2 IPv6 2005:0:0:1:0:0:0:2 Client _LAN_4 19 SW_2 IF3 IPv6 2005:0:0:E:0:0:0:2 SW_1 20 SW_2 IF4 IPv6 2005:0:0:3:0:0:0:2 SW_3 21 SW_3 IF1 IPv6 2005:0:0:5:0:0:0:2 Client _LAN_5 22 SW_3 IF2 IPv6 2005:0:0:4:0:0:0:2 Client _LAN_6 23 SW_3 IF3 IPv6 2005:0:0:3:0:0:0:1 SW_2 24 SW_3 IF4 IPv6 2005:0:0:A:0:0:0:1 SW_4 25 SW_4 IF1 IPv4 192.0.10.1 (with SW_3 default Class C subnet mask) 26 SW_4 IF2 IPv4 192.0.13.1 (with SW_1 default Class C subnet mask) 27 SW_4 IF3 IPv4 192.0.9.2 (with SVR_3 default Class C subnet mask) 28 SW_4 IF4 IPv4 192.0.8.2 (with SVR_2 default Class C subnet mask) 29 SW_4 IF5 IPv4 192.0.7.2 (with SVR_1 default Class C subnet mask)

133 IP Connecting S. IP Address Device name Interface Addressing to Device No. Allocated Scheme Name 30 SW_4 IF6 IPv4 192.0.6.2 (with SVR_4 default Class C subnet mask) 31 SVR_1 IF0 IPv4 192.0.7.1 (with SW_4 default Class C subnet mask) 32 SVR_1 IF0 IPv6 Not Assigned SW_4 33 SVR_2 IF0 IPv4 192.0.9.1 (with SW_4 default Class C subnet mask) 34 SVR_2 IF0 IPv6 Not Assigned SW_4 35 SVR_3 IF0 IPv4 192.0.8.1 (with SW_4 default Class C subnet mask) 36 SVR_3 IF0 IPv6 Not Assigned SW_4 37 SVR_4 IF0 IPv4 192.0.6.1 (with SW_4 default Class C subnet mask) 38 SVR_4 IF0 IPv6 Not Assigned SW_4 39 SW_4 NAT IF1 IPv4 192.0.10.100 (with SW_3 Pool 1 default Class C subnet mask) 40 SW_4 NAT IF2 IPv4 192.0.10.101 (with SW_1 Pool 1 default Class C subnet mask)

The six Client LANs and the switches SW_1 to SW_3 are assigned IPv6 addresses and the four servers along with the switch SW_4 are assigned IPv4 addresses. The NAT pool is configured on SW_4 for translating IPv6 addressed to IPv4 addresses thus allowing the client LANs to communicate with the four servers. As shown in Figure 4.17, the NAT pools are assigned on IF1 and IF2 interfaces as they are connected with switches SW_1 and SW_3 respectively. The NAT is configured for inbound IP packets and hence, the “IP

NAT Inside” settings have been used. The NAT name used is IPv6-to-IPv4_NAT. The same name has been used for defining the IP address pools for translation.

134

Figure 4. 17: NAT configuration-1 on switch SW_4 (Source: Researcher’s OPNET Model)

As presented in Figure 4.18, the NAT source is defined as “Any” and the NAT destination is defined as “0.0.0.0” in the translation access list. This means that any incoming packet will be translated and forwarded to all the networks accessible through the switch SW_4.

This configuration is desirable for Internet traffic because the translation may have to be made effective for thousands of switches and perhaps hundreds of thousands of web servers connected beyond the translating switch. Destination-specific access policies are not feasible on the Internet. The protocol of translation is also set at “Any” and no specific

TCP or UDP port numbers are configured for translation. This means that it is a generalized

NAT configuration for all the inbound traffic irrespective of their type.

135

Figure 4. 18: NAT configuration-2 on switch SW_4 (Source: Researcher’s OPNET Model)

Figure 4.19 presents the NAT pool configurations for both the interfaces IF1 and IF2. The

NAT pool comprises one IPv4 address each for the two interfaces. This configuration will ensure that incoming packets on IF1 get a translated IP address 192.0.10.100 before getting forwarded to the four servers. Similarly, incoming packets on IF1 get a translated IP address 192.0.10.101 before getting forwarded to the four servers. These IP assignments are listed in Table 4.7. The simulation outcomes of NAT design of IPv6 transition are presented and discussed in Sub-Section 4.3.3.

136

Figure 4. 19: NAT configuration-3 on switch SW_4 (Source: Researcher’s OPNET Model)

4.4 Model for Transition from IPv4 to IPv6 Networks: Simulations Results and

Analysis

In this section, the simulation results of the three model designs (dual stack, IP tunneling, and network address translation) are presented and analyzed. The simulations have been conducted based on a report configured with performance and traffic statistics of voice, database queries, and video conferencing applications. The outcomes of simulation of Dual

Stack design are presented and discussed in the next Sub section (4.4.1).

137

4.4.1 Simulation Results’ Analysis of Dual Stack IPv6 Transition

The simulation results of dual stack design of IPv6 transition are used as benchmark for

the other two designs. The reports are generated for the following parameters (chosen based

on the list of statistics in OPNET Modeler):

i. IPv6 packet losses

ii. TCP delays

iii. TCP segment delays

iv. Database query response

v. Database traffic sent and received

vi. Video conferencing packet delay variation

vii. Video conferencing packet end-to-end delay viii. Video conferencing traffic sent and received

ix. Voice jitters

x. Voice MoS value

xi. Voice packet delay variation

xii. Voice packet end-to-end delay xiii. Voice traffic sent and received

Figure 4.20 presents the IPv6 and TCP performance statistics. There were some packet

losses of IPv6 in the beginning. However, this may have been the period when the network

was not stabilized amidst ongoing IP routing updates and broadcasts. Hence, these packet

losses may be ignored.

138

Figure 4. 20: IPv6 and TCP performance of dual stack model (Source: Researcher’s OPNET simulation results)

There is a finite TCP delay and TCP segment delay on the network. Although the delays are recorded in milliseconds, they can serve as benchmarks when analyzing the simulation results of the other three models in this study.

Figure 4.21 presents the overall database query response time and traffic on the network.

The response time of database querying is excellent and somewhat constant at 349.3 milliseconds. The maximum traffic sent and received at a moment is 243.12889 Kbps.

139

Figure 4. 21: Database query performance and traffic of dual stack (Source: Researcher’s OPNET simulation results)

The benchmarks of database querying response time and database traffic are also noted here for comparing with the remaining three models in this study. Figure 4.22 presents the performance statistics and traffic data of video conferencing application. The packet delay variation and packet end-to-end delay are observed as reducing gradually from initial spikes. Although the delay variation and delay statistics have reported values in milliseconds, they cannot be ignored as they are important statistics for comparing with the remaining three models. The video conferencing traffic sent and received increased gradually and peaked at 78.229443.56 Mbps and 78.226560 Mbps respectively when the simulation was stopped. These have been noted as benchmarks, as well.

140

Figure 4. 22: Video conferencing performance and traffic of dual stack model (Source: Researcher’s OPNET simulation results)

Figure 4.23 presents the voice IP telephony performance and traffic statistics in the dual stack IPv6 transition design. Voice jitter is almost negligible as the values (both positive and negative) are in micro-seconds. The Mean Opinion Score (MOS) is the measure of

VoIP voice quality. Its value should be less than 5 for acceptable voice quality. MOS measurement is based on ITU P.861 and ITU P.862 standards. A score in the range of 3.0 to 4.2 is acceptable for VoIP voice quality. The score is very slightly above 3 in Figure

4.23 indicating excellent VoIP performance.

Speech quality has no physical definition. Inherently, people just have an opinion about when something sounds good or bad. However, stakeholders need to be able to quantify the quality delivered by a telephone system in order to maximize investment and ensure

141 adequate service is provided to customers. For many years, the only effective manner by which to determine the quality of a telephone network was to perform a subjective test.

Subject testing involves asking a panel of users what they think of a recording or connection. The panel typically vote on a five point scale, and the average of the votes is deemed to be the quality of the connection. This number is called the mean opinion score

(MOS).

The running of subjective tests is time consuming and costly. During the late 1980s compression technologies were introduced in digital networks to increase capacity while reducing costs. Before their introduction, it was generally possible to determine the performance of a network using simple tone-based measurements. With the introduction of new speech processing technologies, it was found that results from tone-based techniques could contradict users' experiences. A new measurement methodology was required. The increased availability of general purpose computing allowed the development of computer programs capable of modelling the results of subjective tests.

The ITU-T P.861 (perceptual speech quality measure (PSQM) b-ITU-T P.861) recommendation was published in 1996. The core concept introduced in this first generation algorithm was that human hearing could be modelled to extract a representation of audible differences between a reference and a degraded pair of signals, and that these differences could be mapped to the scores of subjective tests.

Shortly after ITU-T P.861 was published, work was started to address practical limitations of the first generation model in terms of its applicability for testing networks. This work led to the publication of a significantly improved model referred to as perceptual evaluation of speech quality (PESQ), published as ITU-T P.862 in 2001, together with ITU-T P.861

142 withdrawal. Work continued on ITU-T P.862 for a number of years, for example, with the introduction of a wideband extension in 2005. However, as more complex signal processing was added to the telephone network, it became clear that a new model was required. In 2006 ITU-T initiated a new activity for the development of the third-generation model. The intention was to provide a backward-compatible model that could also assess new speech signal processing technologies as well as the anticipated move to super wideband networks. The result of this work was published as ITU-T P.863 at the beginning of 2011. It should be noted that the introduction of ITU-T P.863 does not deprecate ITU-T

P.862.

The subjective test purpose to find the average user opinion of the system's speech quality by asking a panel of users a directed question and limited-response choice provision. For instance, to ascertain the listening quality, users are asked to rate 'the quality of the speech' by selecting an opinion against a score: Excellent - 5, Good - 4, Fair - 3, Poor - 2, and Bad

– 1. Apparently, a MOS is calculated for a particular condition by getting the average of the votes of all subjects. This type of test is described as an absolute category rating (ACR) experiment.

The VoIP packet delay variation is in microseconds again, but is increasing gradually indicating that at some stage as the simulation progresses, the quality may degrade.

However, the end-to-end delay of voice packets is constant at 6.027769 milliseconds. The

VoIP traffic increased gradually and reached a peak of 57.52278 Kbps when the simulation was stopped. These observations have been noted down as benchmarks for comparing with the other three models in this study.

143

Figure 4. 23: Voice application performance and traffic of dual stack (Source: Researcher’s OPNET simulation results)

Overall, dual stack design has returned excellent performance results in the simulations.

The simulation results of the IP tunneling and network address translation designs of IPv6 transition are compared with the results benchmarked in this sub-section. Table 4.9 presents a summary of the Sub-section 4.4.2 presents the simulation results of IP tunneling.

144 Table 4. 9: The performance parameters summary for dual stack transition scheme after the end of 180 seconds simulation time IPv6 and TCP DB Query Video Conferencing Voice Application Performance Performance Performance & Performance & Traffic

& Traffic Traffic

s/sec)

ec)

sec)

ponse Time (sec) Time ponse

ceived (bytes/sec) ceived

end Delay end Delay (sec) end

Received (bytes/sec) Received

- -

to to

- -

raffic raffic

Traffic Dropped (packets/sec)Dropped Traffic (sec) TCPDelay (sec) TCPDelay Segment Res Traffic Re Traffic (bytes/sec) Sent Traffic Delay Variation Packet End T (bytes/s Sent Traffic (sec) Jitter Value MOS Delay Variation Packet End (byte Received Traffic (bytes/ Sent Traffic

Dual Stack Model

560 443.56

, ,

128.89 128.89

, ,

226 229 8086872 522.78

, , ,

001435

0.0000000619

0 0.001341 0.000183 0.03493 243 243 0.000116 0. 78 78 - 3.0 0.000000085 0.0602776 57 57,522.78

4.4.2 Simulation Results’ Analysis of IP Tunneling Design of IPv6 Transition

In this sub-section, the simulation results of IP tunneling design are presented and discussed. Figure 4.24 presents the IPv6 packets dropped and TCP performance metrics.

After a brief initial period, when the network is establishing through routing protocols, there are some IPv6 packet losses. Thereafter, no packet losses have been reported. TCP delay peaks at 1.203 milliseconds and TCP segment delay peaks at about 0.165 milliseconds. Comparing with Figure 4.20 of the dual stack model, the performance appears to be slightly improved as the same indicators are reported at 1.341 milliseconds and 0.183 milliseconds in the dual stack model.

145

Figure 4. 24: IPv6 and TCP performance of IP tunneling model (Source: Researcher’s OPNET simulation results)

As reported in Figure 4.25, the database query response time is at 347.11 milliseconds for a traffic volume reaching 258.858666667 kilobytes per second in both sent and received traffic. Comparing with Figure 4.21, this performance is reported as slightly identical to that of dual stack design with the database query response time at 349.3 milliseconds for a traffic volume reaching 243.12889 kilobytes per second in both sent and received traffic.

146

Figure 4. 25: Database query performance and traffic of IP tunneling model (Source: Researcher’s OPNET simulation results)

However, video traffic seems to have improved significantly in IP tunneling design. The video packet delay variation increased gradually to 0.96 milliseconds and then dropped gradually to a mere 0.042 milliseconds. In comparison, as evident in Figure 4.22, the video packet delay variation remained between 1.076 milliseconds and 0.965 milliseconds for quite some time in dual stack design and finally reduced to 0.215 milliseconds and later to

0.116 milliseconds. While the network finally stabilized to 0.1 milliseconds in both the designs, the video delay remained at a much higher value in dual stack design for a while.

The end-to-end packet delay started from 6.277 milliseconds and later stabilized at 1.913 milliseconds in the IP tunneling design. In comparison, the end-to-end packet delay in dual stack design started from 15.633 milliseconds and finally settled at 1.435 milliseconds after

147 reducing gradually. If this is a cyclic trend, then video performance may cyclically degrade and then improve in dual stack design while IP tunneling design may provide more stable performance. The traffic volume peaked at 77.241610666667 Mbps and 78.22944356

Mbps in both dual stack and IP tunneling designs and hence this is a fair comparison of performances.

Figure 4. 26: Video conferencing performance and traffic of IP tunneling model (Source: Researcher’s OPNET simulation results)

The voice performance in IP tunneling design is, however, inferior to the dual stack design.

The jitter and packet delay variation patterns reported in Figure 4.27 reveal that they are higher than the report in Figure 4.23 for dual stack model. Further, end-to-end packet delay in IP tunneling is 100.19892 milliseconds and the MOS value reported in IP tunneling is

2.517918703 (Figure 4.27). However, dual stack design reported end-to-end packet delay

148 at 60.27769 milliseconds and MOS value at 3.080868722 (Figure 4.23). MOS value of 2.5 is anyways less than the acceptable range of 3.0 to 4.2 thus making IP tunneling design not suitable for voice. Perhaps, the encryption overhead causes the harm.

Figure 4. 27: Voice application performance and traffic of IP tunneling model (Source: Researcher’s OPNET simulation results)

149 Table 4. 10: The performance parameters comparison summary for dual stack and 6to4 tunneling transition schemes after the end of 180 seconds simulation time IPv6 and TCP DB Query Video Conferencing Voice Application Performance Performance Performance & Performance & Traffic

& Traffic Traffic

Time (sec) Time

lay (sec) lay

(bytes/sec)

end Delay end Delay (sec) end

- -

to to

- -

raffic Received (bytes/sec) Received raffic

Traffic Dropped (packets/sec)Dropped Traffic (sec) TCPDelay TCPDe Segment Response Traffic (bytes/sec) Received Traffic (bytes/sec) Sent Traffic Delay Variati Packet End Received Traffic (bytes/sec) Sent Traffic (sec) Jitter Value MOS Delay Variation Packet End T (bytes/sec) Sent Traffic

Dual Stack Model

.56

43,128.89

0.0000000619

0 0.001341 0.000183 0.03493 243,128.89 2 0.000116 0.001435 78,226,560 78,229,443 - 3.080868722 0.000000085 0.06027769 57,522.78 57,522.78

Tunneling Model

050

03 65

,069.166666667

0012

0.034711 58,858.666667

0.000000

0 0. 0.0001 0 2 258,858.666667 0.000042 0.001913 77,238,720 77,241,610.666667 - 2.517918703 0.000000040 0.100198920 60,070 60

4.4.3 Simulation Results’ Analysis of Network Address Translation IPv6 Transition

This subsection presents the simulation results of NAT design and their comparison with the results of dual stack design. The IPv6 traffic drops and TCP performance of the NAT design are almost identical with those of the dual stack design (Figure 4.28 compared with

Figure 4.20).

150

Figure 4. 28: IPv6 and TCP performance of IP-NAT model (Source: Researcher’s OPNET simulation results)

Further, the DB query performance reports of NAT design (Figure 4.29) are almost identical with those of dual stack (Figure 4.21) and IP tunneling (Figure 4.25). The differences are evident in video and voice performances.

151

Figure 4. 29: Database query performance and traffic of IP NAT model (Source: Researcher’s OPNET simulation results)

The video conferencing packet delay variation increased gradually from 0.875 milliseconds to 0.989 milliseconds, then decreased gradually to 0.072 milliseconds and finally settled at 0.037 milliseconds (Figure 4.30). This performance is superior to that of dual stack design (Figure 4.22) but is inferior to IP tunneling design (Figure 4.26). The packet end-to-end delay started from a peak of 18.22 milliseconds, dropped to 1.542 milliseconds then 1.399 milliseconds and stabilized at 1.366 milliseconds (Figure 4.22).

The performance stabilizing at 1.366 milliseconds is almost similar to that of the IP tunneling design at 1.913 milliseconds (Figure 4.26), but the initial peak of 18.22 milliseconds makes the video performance of NAT design inferior to IP tunneling design

152 (Figure 4.30). The video performance of NAT design is slightly inferior to dual stack design, as the latter had an initial peak of 15.633 milliseconds (Figure 4.22).

Figure 4. 30: Video conferencing performance and traffic of IP-NAT model (Source: Researcher’s OPNET simulation results)

Again, the video traffic was 80.34624711 Mbps for sent and 80.34624711 Mbps for received traffic, which is slightly identical to dual stack (at 78.22944356 Mbps and

78.226560 Mbps) and IP tunneling designs (at 77.241610666667 Mbps and 77.238720

Mbps). Hence, it is a fair comparison. The voice performance of NAT design is clearly superior to that of IP tunneling design as the MOS is reported at 3.080872556 in NAT design (Figure 4.31) as against 2.517918703 of IP tunneling design (Figure 4.27).

153 However, the voice performance of NAT design (Figure 4.31 is almost similar to that of dual stack design (Figure 4.31 compared with Figure 4.23) with slightly inferior in terms of jitter and packet delay variation, but with identical MOS value and end-to-end packet delay variation. It can be safely concluded that the voice performance of NAT design is equivalent to that of dual stack design.

Figure 4. 31: Voice application performance and traffic of IP NAT model (Source: Researcher’s OPNET simulation results)

4.5 Discussion

In the Sections 4.3 and 4.4, detailed modelling and analysis of schemes for translating IPv6 to IPv4 in a cloud computing environment were carried out. The schemes modelled were

154 dual-stack, IP tunneling, and network address translation. The purpose of such detailed modelling and efforts and analysis was to explore the performances of data access

(measured through response times of database queries), video conferencing (measured through video packet delay variations and end-to-end packet delays), and IP telephony voice communications (measured through jitters, mean opinion score, packet delay variations, and end-to-end packet delays). Special care was taken to ensure that the amount of traffic and network loads remain identical in the three scenarios. Further, it was found that network throughput remained comparable in the three scenarios, perhaps because the network is a cloud environment with high end servers and links of high capacities. From the simulation results, the following observations were made:

(a) Dual Stack and NAT having comparable performances for Voice, but IP tunneling

returned higher jitters, and more significantly, an unacceptable MOS value (at 2.5

while the acceptable range is between 3 and 4.2).

(b) IP tunneling returned a stable performance of video with packet delay variation

settling after a small initial variation. However, both dual stack and NAT resulted

in high initial variation before settling at almost the same value of video packets

delay as that of IP tunneling.

comparable.

Can these results be treated as empirical? Given that these results are obtained from modelling and simulations of a small-scale cloud with specific types of routers and servers, they cannot be generalized or treated as empirical. These performances may vary based on numbers and types of switches, routers, and servers.

155

4.6 Conclusion

This study tested automated 6to4 tunneling with dual stack and NAT and hence it was preferred in the final design. The criteria for this choice was as follows:

a) The IPv4 addresses are limited to about 4.3 billion and may get exhausted in future.

Hence, in an ideal design all the equipment, servers, clients, and interfaces should

be configured on IPv6. This is the primary reason an economic IPv6 transition

method is needed.

b) Dual stack configuration requires equal number of IPv4 and IPv6 addresses and

hence defeats the fundamental purpose for designing an optimal IPv6 transition

method. It is not a choice even if it performs the best in most of the cases. Hence,

while it may be used for small LANs already having IPv6 addresses, it is not

suitable for large networks.

c) NAT may be good for small number of concurrent connections. However, when a

large number of client machines are communicating, NAT will require a massive

pool of IPv4 addresses and hence may not be suitable. In large networks, a large

number of concurrent client connections is expected. Hence, NAT is judged as

unsuitable for such networks. Given its lack of viability for long-term usage, it has

been rejected in the design of this study.

d) Automated 6to4 tunneling has been recommended by all the research studies

reviewed in Table 4.4. The primary advantage of this technology is that it requires

only one IPv4 address per tunnel for unlimited number of concurrent sessions.

156 However, encryption overheads cause increased voice jitters resulting in low MOS

values, as was observed in this study.

e) However, if voice traffic and video traffic are segregated flowing to different server

farms, then the jitters can be reduced improving the MOS value.

f) Voice performance of IP 6to4 tunneling can also be improved by prioritising voice

traffic through Quality of Service (QoS) settings based on Type of Service (ToS).

4.7 Summary

The performance observations are used as the fundamental observations from the simulation results that provide direction for the design of an original application for IPv6 transition. The overall analysis of the simulation results, some evidences from literature, and design details of the original application are all presented in the Section 4.4. The summary of performance parameters for dual stack, 6to4 IP tunneling, and Network

Address Translation transition schemes is presented in Table 4.11 for easier comparison.

Table 4. 11: The performance parameters comparison summary for dual stack, 6to4 tunneling, and Network Address Translation transition schemes after the end of 180s simulation time Simulation Time (sec) Transitio IPv6 Traffic Dropped (packets/sec) n

Scheme 0m 0s 0m 36s 1m 12s 1m 48s 2m 24s 3m 0s

Dual stack 6.111111 0 0 0 0 0

6.7222

Tunneling 0 0 0 0 0

157

NAT 6.722222 0 0 0 0 0

TCP Delay (sec)

- -

Dual stack 0.000467 0.00109 0.001198 0.001341

eling

203

- -

Tunn 0.000455 0.000835 0.001073 0.001

- -

NAT 0.000456 0.000988 0.001246 0.001357

TCP Segment Delay (sec)

75 83

- -

Dual stack 0.0000 0.000151 0.000169 0.0001

- -

Tunneling 0.000069 0.000133 0.000153 0.000165

NAT - 0.000069 0.000148 0.000172 0.000188

DB Query Response Time (sec)

- -

Dual stack 0.033536 0.034516 0.034773 0.03493

- -

Tunneling 0.033509 0.034178 0.034545 0.034711

158

- -

NAT 0.0335 0.034424 0.03484 0.034991

DB Query Traffic Received (bytes/sec)

,773.33

Dualstack 0 0 2 219,093.33 180,266.67 243,128.89

nneling

Tu 0 0 7,395.555556 242,204.444444 219,093.333333 258,858.666667

72,871.11

NAT 0 0 7,395.56 233,884.44 1 217,244.44

DB Query Traffic Sent (bytes/sec)

Dualstack 0 0 2,773.33 219,093.33 180,266.67 243,128.8

Tunneling 0 0 7,395.555556 242,204.444444 219,093.333333 258,858.666667

NAT 0 0 7,395.56 233,884.44 172,871.11 217,244.44

Video Conferencing Packet Delay Variation

ual

- -

D stack 0.001076 0.000965 0.000215 0.000116

159

- -

Tunneling 0.000096 0.00077 0.000065 0.000042

0989

- -

NAT 0.000875 0.00 0.000072 0.000037

Video Conferencing Packet End-to-End Delay (sec)

- -

Dual stack 0.015633 0.001592 0/001441 0.001435

- -

Tunneling 0.006277 0.002331 0.002014 0.001913

1399

- -

NAT 0.01822 0.001542 0.00 0.001366

Video Conferencing Traffic Received (bytes/sec)

Dualstack 0 0 87,360 59,275,200 74,501,760 78,226,560

905,600

Tunneling 0 0 21,120 58, 72,771,840 77,238,7

NAT 0 0 20,160 60,682,560 76,587,840 80,347,200

Video Conferencing Traffic Sent (bytes/sec)

,276,275.56

Dualstack 0 0 90,247.111111 59 74,502,730.67 78,229,443.56

160

1111

Tunneling 0 0 21,121.777778 58,909,559.111111 72,771,847.11 77,241,610.666667

NA 0 0 21,121.78 60,683,644.44 76,586,887.11 80,346,247.11

Voice Jitter (sec)

tack

0000329

0.0000000916 0.0000001044 0.0000000619

- -

Duals - - 0.000 -

0.000000311 0.000000050

- -

Tunneling 0.000000521 0.000000084 - -

0.0000001697 0.0000000084 0.0000001258

- -

NAT - 0.0000001243 - -

Voice MOS Value

.080868722

- -

Dualstack 3.080868 3.080868722 3 3.080868722

8703

Tunneling - 2.517819300 2.51791 2.517918703 2.517918703

161

- -

NAT 3.080772 3.080872556 3.080872556 3.080872556

Voice Packet Delay Variation

- -

Dualstack 0.0000000001 0.00000000458 0.0000000741 0.000000085

- -

Tunneling 0 0.000000026 0.000000035 0.000000040

0086

- -

NAT 0.0000000003 0.0000000606 0.00000 0.0000000961

Voice Packet End-to-End Delay (sec)

06019842

ualstack

- -

D 0.060029 0. 0.06025677 0.06027769

.100198920

- -

Tunneling 0.100034885 0.100144073 0.100170904 0

- -

NAT 0.060035 0.0601967 0.060252848 0.060282445 Voice Traffic Received (bytes/sec)

162

Dual stack 0 0 245.2778 44,222.22 54,834.1 57,522.78

Tunneling 0 0 125.833333333 44,598.333333333 54,457.5 60,070

NAT 0 0 119.7222 42,917.78 55,584.17 62,270.56

Voice Traffic Sent (bytes/sec)

Dual stack 0 0 245.2778 44,223.06 54,835.56 57,522.78

66667

4,458.333333333

Tunneling 0 0 125.833333333 44,598.333333333 5 60,069.1666

NAT 0 0 119.7222 42,917.78 55,584.17 62,270.56

163 CHAPTER FIVE

MODEL DEVELOPMENT

5.1 Introduction

In the Sections 4.3 and 4.4, detailed modelling and analysis of schemes for transition in a cloud computing environment were carried out. The schemes modelled were dual-stack,

IP tunneling, and network address translation. This study tested automated 6to4 tunneling with dual stack and NAT and hence it was preferred in the final design. The criterion for this choice has been presented in the previous chapter. Keeping this aspect into account, the designing of original IPv6 Transition Controller Application has been executed in this chapter.

5.2 Overall Design and Analysis of an Original Application for IPv6 Transition

Keeping the criteria highlighted above in mind, an original IPv6 Transition Controller

Application design has been created, modelled in OPNET, and tested through simulations.

Figure 5.1 presents the redesigned network for ensuring that the IPv6 Transition Controller can control all the voice, video, and data sessions through “traffic recognition and routing” and also verifying the ToS status of the traffic and controlling the prioritization accordingly. The ToS status of the running traffic is determined with the help of a ToS DB having relational records defining traffic shapes and their priority levels. The IPv6

Transition Controller is directed by the IPv6 Transition App. The Servers SVR_1 and

SVR_2 are now dedicated for data, SVR_3 and SVR_4 are dedicated for voice, and SVR_5 and SVR_6 are dedicated for video. There are additional servers and switches in the design as compared with the previous models.

164

Figure 5. 1: Network reorganization for running the original IPv6 transition controller application design created in this study for IPv6 transition (Source: Researcher’s OPNET Model)

The details of all devices, interfaces, IP address schemes and allocation, and connecting devices (next hops) are presented in Table 5.1. It may be observed that the network design is now more complex than the previous three models presented in this study for the three

IPv6 transition schemes. The new design has six switches and six servers (instead of four for each category in the previous designs).

The network has now three distinct paths: SW_2 → SW_1 → SW_4 →SVR_1 / SVR_2 for data, SW_2 → SW_5 → SVR_3 / SVR_4 for voice, and SW_2 → SW_3 → SW_6 →

SVR_5 / SVR_6 for video. It may be observed that the number of hops for voice traffic path has been deliberately kept smaller keeping in mind the limitation of IP 6to4 tunneling in handling the voice traffic. Thus, the network is now reorganized to work for the IPv6

Transition Controller, and the IPv6 Transition App.

165 Table 5. 1: IP address assignments in the original IPv6 transition controller application implementation of IPv6 transition (Source: Researcher’s model in OPNET) IP Interfac IP address Connecting to S. No. Device Name Addressin e Allocated Device Name g Scheme 1 Client IF0 IPv6 2005:0:0:12:0:0:0:1 SW_1 _LAN_1 2 Client IF0 IPv4 Not allocated SW_1 _LAN_1 3 Client IF0 IPv6 2005:0:0:11:0:0:0:1 SW_1 _LAN_2 4 Client IF0 IPv4 Not allocated SW_1 _LAN_2 5 Client IF0 IPv6 2005:0:0:10:0:0:0:1 SW_2 _LAN_3 6 Client IF0 IPv4 Not allocated SW_2 _LAN_3 7 Client IF0 IPv6 2005:0:0:1:0:0:0:1 SW_2 _LAN_4 8 Client IF0 IPv4 Not allocated SW_2 _LAN_4 9 Client IF0 IPv6 2005:0:0:E:0:0:0:1 SW_3 _LAN_5 10 Client IF0 IPv4 Not allocated SW_3 _LAN_5 11 Client IF0 IPv6 2005:0:0:F:0:0:0:1 SW_3 _LAN_6 12 Client IF0 IPv4 Not allocated SW_3 _LAN_6 13 SW_1 IF1 IPv6 2005:0:0:6:0:0:0:2 SW_2 14 SW_1 IF2 IPv6 2005:0:0:5:0:0:0:1 SW_4 15 SW_1 IF3 IPv6 2005:0:0:12:0:0:0:2 Client _LAN_1 16 SW_1 IF4 IPv6 2005:0:0:11:0:0:0:2 Client _LAN_2 17 SW_2 IF1 IPv6 2005:0:0:10:0:0:0:2 Client _LAN_3 18 SW_2 IF2 IPv6 2005:0:0:1:0:0:0:2 Client _LAN_4 19 SW_2 IF3 IPv6 2005:0:0:6:0:0:0:1 SW_1 20 SW_2 IF4 IPv6 2005:0:0:2:0:0:0:1 SW_3 21 SW_2 IF5 IPv6 2005:0:0:9:0:0:0:1 SW_5 22 SW_2 IF6 IPv6 2005:0:0:D:0:0:0:1 IPv6_Transitio n_ Controller

166 IP Interfac IP address Connecting to S. No. Device Name Addressin e Allocated Device Name g Scheme 23 SW_3 IF1 IPv6 2005:0:0:E:0:0:0:2 Client _LAN_5 24 SW_3 IF2 IPv6 2005:0:0:F:0:0:0:2 Client _LAN_6 25 SW_3 IF3 IPv6 2005:0:0:2:0:0:0:2 SW_2 26 SW_3 IF5 IPv6 2005:0:0:A:0:0:0:1 SW_6 27 SW_4 IF1 IPv6 2005:0:0:4:0:0:0:2 SVR_1 28 SW_4 IF1 IPv4 192.0.4.2 (with SVR_1 default Class C subnet mask) 29 SW_4 IF2 IPv6 2005:0:0:5:0:0:0:2 SW_1 30 SW_4 IF2 IPv6 192.0.5.1 (with SW_1 default Class C subnet mask) 31 SW_4 IF3 IPv6 2005:0:0:3:0:0:0:2 SVR_2 32 SW_4 IF3 IPv6 192.0.3.2 (with SVR_2 default Class C subnet mask) 33 SW_5 IF1 IPv6 2005:0:0:9:0:0:0:2 SW_2 34 SW_5 IF1 IPv6 192.0.9.1 (with SW_2 default Class C subnet mask) 35 SW_5 IF2 IPv6 2005:0:0:8:0:0:0:2 SVR_3 36 SW_5 IF2 IPv6 192.0.8.2 (with SVR_3 default Class C subnet mask) 37 SW_5 IF3 IPv6 2005:0:0:7:0:0:0:2 SVR_4 38 SW_5 IF3 IPv6 192.0.7.2 (with SVR_4 default Class C subnet mask) 39 SW_6 IF1 IPv6 2005:0:0:7:0:0:0:2 SVR_6 40 SW_6 IF1 IPv6 192.0.10.1 (with SVR_6 default Class C subnet mask) 41 SW_6 IF2 IPv6 2005:0:0:B:0:0:0:2 SVR_5 42 SW_6 IF2 IPv6 192.0.11.2 (with SVR_5 default Class C subnet mask) 43 SW_6 IF3 IPv6 2005:0:0:C:0:0:0:2 SW_3 44 SW_6 IF3 IPv6 192.0.12.2 (with SW_3 default Class C subnet mask)

167 IP Interfac IP address Connecting to S. No. Device Name Addressin e Allocated Device Name g Scheme 45 SVR_1 IF0 IPv4 192.0.4.1 (with SW_4 default Class C subnet mask) 46 SVR_1 IF0 IPv6 Not Assigned SW_4 47 SVR_2 IF0 IPv4 192.0.3.1 (with SW_4 default Class C subnet mask) 48 SVR_2 IF0 IPv6 Not Assigned SW_4 49 SVR_3 IF0 IPv4 192.0.8.1 (with SW_5 default Class C subnet mask) 50 SVR_3 IF0 IPv6 Not Assigned SW_5 51 SVR_4 IF0 IPv4 192.0.7.1 (with SW_5 default Class C subnet mask) 52 SVR_4 IF0 IPv6 Not Assigned SW_5 53 SVR_5 IF0 IPv4 192.0.11.1 (with SW_6 default Class C subnet mask) 54 SVR_5 IF0 IPv6 Not Assigned SW_6 55 SVR_6 IF0 IPv4 192.0.12.1 (with SW_6 default Class C subnet mask) 56 SVR_6 IF0 IPv6 Not Assigned SW_6 57 SW_5 Tunnel Tunnel1 IPv4 192.168.4.1 (with SW_2 default Class C subnet mask) 58 SW_5 Tunnel Tunnel1 IPv4 192.0.9.1 (with SW_2 Interface default Class C subnet mask) 59 SW_2 Tunnel Tunnel0 IPv6 2005:0:0:9:0:0:0:10 SW_5 Interface 0 59 SW_4 Tunnel Tunnel1 IPv4 192.168.1.1 (with SW_1 default Class C subnet mask) 60 SW_4 Tunnel Tunnel1 IPv4 192.0.5.1 SW_1 Interface 61 SW_1 Tunnel Tunnel0 IPv6 2005:0:0:5:0:0:0:10 SW_4 Interface 0 61 SW_6 Tunnel Tunnel1 IPv4 192.168.2.1 (with SW_3 default Class C subnet mask)

168 IP Interfac IP address Connecting to S. No. Device Name Addressin e Allocated Device Name g Scheme 62 SW_6 Tunnel Tunnel 1 IPv4 192.0.10.1 SW_3 Interface 63 SW_3 Tunnel Tunnel 0 IPv6 2005:0:0:A:0:0:0:1 SW_6 Interface 00 64 IPv6_Transiti IF0 IPv6 2005:0:0:D:0:0:0:2 SW_2 on_Controller

The ToS DB, the IPv6 Transition Controller, and the IPv6 Transition App are new additions in the model. The runtime profiles and the applications are also modified based on the new application and its interactions as defined under the IPv6 Transition Controller and the IPv6 Transition App. All the configuration details about the three added design components and the additions in the runtime profiles and the applications are discussed after Table 5.1. This model and its performance analysis are the original contributions of this study. The three server groups for data, voice, and video are now accessible only through IP 6to4 tunneling. The reasons are explained in the design criteria prior to the Table

5.1 and the model design in Figure 5.1.

Figure 5.2 presents the interactions design in the IPv6 Transition App that it uses to direct the IPv6 Transition Controller. It may be noted that the ToS DB is a crucial component of this design, which is further explained and demonstrated in this section. The IPv6

Transition App has three workflows of request-response interactions, each for traffic recognition and routing for data, voice, and video requests. The Client LANs have been reconfigured (in the destination settings) to first consult the IPv6 Transition Controller before starting any traffic to the servers. Further, it may be observed in Figure 5.2 that the

IPv6 Transition Controller first consults the ToS DB before responding to the requesting

169 LANs. The ToS DB is the key component in this design for deciding about traffic recognition and then routing it appropriately.

Figure 5. 2: Three workflows of the original IPv6 transition controller application, each with four transactions in request-response mode (Source: Researcher’s OPNET Model)

Figure 5.3 presents the destination settings of IPv6 Transition Controller. The entire client

LANs have been configured as destination preferences for responding to DB destination query (or may be simply named as data destination query). Similar settings have been done for responding to voice destination query, and video destination query. For example, the destination settings for video destination query response are shown in Figure 5.4.

170

Figure 5. 3: Destination settings for responses of IPv6 transition controller for DB destination query (Source: Researcher’s OPNET Model)

171

Figure 5. 4: Destination settings for responses of IPv6 transition controller for video destination query (Source: Researcher’s OPNET Model)

The ToS DB is an integral component of the IPv6 Transition Controller (Figure 5.5).

Hence, the destination setting for sending query to the ToS DB is pointing towards the transition controller itself. This is to ensure that all queries are resolved locally before the requests from the Client LANs are responded after making decisions about traffic recognition and then routing the traffic appropriately. The ToS DB is the key component in this design and is therefore discussed in detail after the Figure 5.5. Figure 5.1 shows the addition of ToS DB in the model.

172

Figure 5. 5: Destination settings for responses of IPv6 transition controller for type of service (ToS) DB (Source: Researcher’s OPNET Model)

The ToS DB records are presented in Figure 5.6 to Figure 5.9. Figure 5.6 presents mapping of traffic classification schemes, the priority labels, and maximum queue sizes (similar to records in a relational database table).

173

Figure 5. 6: Relational ToS DB records entries: relating the maximum queue sizes, priority labels, and services categories (Source: Researcher’s OPNET Model)

There are four priority labels defined as presented in Figure 5.6. The queue sizes are reducing with increase of priority labels. The streaming and interactive multimedia traffic are positioned at priority label “Medium” with a maximum queue size of 40 and the interactive voice and reserved traffic are positioned at priority label “High” with a maximum queue size of 20. Thus, interactive voice and reserved traffic will have higher

174 priority than streaming or interactive video. This means that there may be scenario when the video packets of a running interactive video session may be delayed but the voice gets through earlier. This may result in some time lag and lip syncing issues if there are longer queues of video packets; but the voice session will run smoothly. However, in case of multimedia streaming, both voice and video will be affected simultaneously if there is a longer queue of packets.

Figure 5. 7: Relational ToS DB records entries: relating the byte counts, maximum queue sizes, and services categories (Source: Researcher’s OPNET Model)

Figure 5.7 presents another relational table in the ToS DB in which, the maximum bytes allowed, maximum queue lengths allowed, and the traffic classification schemes are mapped. In this ToS setting, applications with higher priority will be allowed higher number of bytes in the packets (that is, larger packet sizes will be allowed). As per the

175 settings, voice and reserved categories will be allowed larger packet sizes such that even if their queues are long (say, reaching the maximum queue size of 20), the quality of application delivery will be better because of “more content delivered with each packet delivery”.

Figure 5. 8: Relational ToS DB records entries: relating the reservation policies with bandwidth and buffer sizes (Source: Researcher’s OPNET Model)

Figure 5.8 defines what it means to have a “reserved category”. As per this Figure, a bandwidth of 5 Kbps and a buffer size (in switches) of 5 KB will be reserved per packet for each sender allowed in this category. This setting has been designed keeping a “most probable value” of the packet sizes in mind and may be increased if the applications are expected to send packets of higher sizes more frequently. For example, if the senders in

176 “reserved” category tend to use their maximum quota of 16 KB more frequently (although unlikely; as the network is not designed to reach such high congestion levels), then the buffer reservation may be increased by this value and the bandwidth reservation may also be increased to 16 Kbps.

Figure 5. 9: Relational ToS DB records entries: relating the traffic policy with average rate, normal burst size, excess burst size (Source: Researcher’s OPNET Model)

Finally, traffic limits are defined for average, normal, and excess bursts. If the excess traffic bursts occur on any type of service, application type, or TCP/UDP port, it will be treated as congestion threshold and any further traffic will be dropped. This explains why it is unlikely for the reserved category to send traffic with maximum packet sizes. This rule of traffic limits is applicable for any sender irrespective of the priority labels and privileges.

It is like if a motorway is congested, even the vehicles of VVIPs will be stopped at a barrier.

177

Figure 5. 10: Defining IPv6 transition controller as a custom application and ToS DB as a medium load database; these are essential for simulations (Source: Researcher’s OPNET Model)

As shown in Figure 5.10, the ToS DB has been configured as a medium load database application. OPNET has in- built parameters for load generation based on such levels. A designer can create custom loading profiles as well, based on knowledge of loading profiles in an actual organization. However, capturing loading profiles from actual networks requires multiple packet capture probes for data collection, which can collectively capture thousands of packets of different applications and determine the loading profiles running on the network. It is very difficult to get such permissions from an organization for capturing packets. Hence, to demonstrate the design working in a simulation environment

OPNET’s internal loading profiles are used. The runtime profile for the IPv6 transition

178 controller application used in the simulation is presented in Figure 5.11. The duration is fixed at 50 seconds with an offset of 5 to 10 seconds. In reality, the duration shall vary dynamically based on the number of requests received and processed by the IPv6 transition controller application.

Figure 5. 11: Defining runtime settings for IPv6 transition controller; these are essential for simulations (Source: Researcher’s OPNET Model)

After completing the above settings, multiple simulations were executed. The findings of the modelled simulations are analyzed in the next section.

5.3 Simulation Results’ Analysis of the Original Application for IPv6 Transition

The simulation results have been presented in two parts. The first part presents the results related with the IPv6 transition controller application, and the second part presents the

179 results for comparisons with the previous three IP transition scenarios (dual stack, IP tunneling, and IP NAT) modelled, simulated, and analyzed in this study.

5.3.1 IPv6 Transition Controller Application Operations Simulation Results’

Analysis

Figure 5.12 presents average phase response times of the three tasks of the application: traffic recognition and routing of data traffic, voice traffic, and video traffic. The phase response times have been returned as one second in the three phases. This response time is unavoidable because the response steps involves running a quick query on the ToS DB before making and communicating the routing decision to the requester. This one second may extend further if there is a long queue of requests to be processed. However, this should not affect the performance of the overall network because execution of these phases will be needed only once before the traffic volumes are triggered.

As presented in Figure 5.12, the phases are completed within a short period of 75 seconds

(between 75 and 150 seconds of the simulation). The curve is triangular indicating that the peak workload of processing the requests occurred between 100 and 110 seconds of the simulation. Once the requests have been processed, there is no traffic related to IPv6

Transition Controller Application. In real world scenario, this triangular pattern may repeat randomly with varying peaks as the requests from clients are expected to arrive randomly in a stochastic manner.

180

Figure 5. 12: Packet network delay, response times, and overall traffic of each of the three phases of IPv6 transition controller application executed for traffic recognition and routing of data, video, and voice traffic (Source: Researcher’s OPNET simulation results)

The overall packet network delay for executing the IPv6 Transition Controller Application reported in Figure 5.12 is 0.1 Milliseconds. This delay is very small and is independent of the actual data, voice, and video delays and will add to the phase execution time for

181 executing the requests. In addition, there are additional delays to be accounted that are caused by introducing the application in the network.

Figure 5. 13: Response times and traffic of initial application demands raised by two of the Client LANs to the IPv6 transition controller application executed for requesting for traffic recognition and routing of data, video, and voice traffic (Source: Researcher’s OPNET simulation results)

Figure 5.13 presents the delays caused by a few clients in making the requests to the application. These delays are again very small (approximately 0.1 Milliseconds) but will add to delay in actual traffic starting. The traffic volumes are very small for making the requests (between 6 to 30 bytes per seconds). Figure 5.14 to Figure 5.17 further show the overall scenario of the client requests made to the IPv6 Transition Controller Application.

For every request made, the application sends an acknowledgement to each client such that

182 the client does not repeat the request. Thereafter, the client has to wait till the application provides traffic routing information for the requested traffic: data, voice, video, or a combination of the three that may result in a session split into multiple streams routed through different paths on the network.

Figure 5. 14: Request-Response round trip times of each of the three phases of IPv6 transition controller application executed for traffic recognition and routing of data, video, and voice traffic (Source: Researcher’s OPNET simulation results)

Figure 5.14 presents the round trip delay of the request-response cycles being a maximum of 0.3 milliseconds for the requests and decisions made to route data traffic, voice traffic, and video traffic. Further, the traffic routing decisions for the client is based on the query output of the ToS DB. Hence, after this round trip delay, a waiting period for getting the final confirmation from the application is added.

183

Figure 5. 15: Request and response packet network delays of each of the three phases of IPv6 transition controller application executed for traffic recognition and routing of data, video, and voice traffic (Source: Researcher’s OPNET simulation results)

Figure 5.15 further shows the overall packet network delays of both the request and response cycles. The requests (as observed in Figures 5.13, 5.14, and 5.15) are of short durations (maximum 30 seconds) and the responses are the ones responding with full traffic routing information thus extending to the maximum duration of 75 seconds as observed in

Figures 5.12 and 5.13.

184

Figure 5. 16: Overall requests and response traffic to/from the IPv6 transition controller application executed for traffic recognition and routing of data, video, and voice traffic (Source: Researcher’s OPNET simulation results)

The maximum packet network delays are recorded at a slightly above 0.1 milliseconds for the overall requests and responses pertaining to routing decision-making of data, voice, and video traffic. The overall traffic for completing the cycles of requests and responses is as presented in Figure 5.16. The requests from clients comprise of small traffic volumes: between 80 to 90 bytes per second. However, the responses from the IPv6 transition controller application comprise of larger traffic volumes: between 5.0 to 5.5 Kbps.

185 The last simulation report analyzed in this part of simulations (related to the IPv6 transition controller application) is related with the size of packets in the requests and the requests per second handled by the application (Figure 5.17). The requesting packet sizes are fixed at 1000 bytes. Further, the number of requests per second handled by the application peaked at five requests per second in this simulation.

The request sizes are the same as the minimum sizes defined in the application because there are no overheads in this simulation period. This is because the peak number of requests per second handled by the application is six only. This is why the overall round trip delay of the request response cycles peaked at 0.3 milliseconds only.

Combining with the response time performance of ToS DB query of one second, the average total time taken for the application to complete the processing of a request will be

1.3 seconds. This performance will be quite acceptable because it will occur only once before establishment of the data, video, or voice session. In complex networks, like grid and cloud computing, this application may have to be run in multiple instances such that each instance can undertake the services overhead of its neighbouring virtualized machines.

186

Figure 5. 17: Overall sizes and load of all requests sent to the IPv6 transition controller application for traffic recognition and routing of data, video, and voice traffic (Source: Researcher’s OPNET simulation results)

This sub-section presented the analysis of operations of the IPv6 transition controller application. The next sub-section presents comparison of its performance with the previous three designs of IPv6 transition discussed in this study.

187 5.3.2 Simulation Results’ Analysis related to comparison of operations of the IPv6

Transition Controller Application with the previous three IPv6 Transition Designs

The simulations have been conducted to collect the results for the 13 performance parameters presented in Sub-Section 4.3.1 and later collected for the three IPv6 transition scenarios: dual stack, IPv6 tunneling, and IP NAT. The first performance is related with overall TCP delay and TCP segment delay (Figure 5.18 compared with Figures 4.20, 4.24, and 4.28).

Figure 5. 18: TCP performance after completing the three phases of IPv6 transition controller application (Source: Researcher’s OPNET simulation results)

The overall TCP delay at a peak value between 0.738 and 1.058 milliseconds is better than dual stack, IP tunneling, and IP-NAT but quite close to the 1.2 milliseconds recorded in IP tunneling. But TCP segment delay is almost equal to dual stack, slightly higher than IP

Tunneling, and slightly lower than IP NAT. The next performance comparison is with regard to database query performance (Figure 5.19 compared with Figures 4.21, 4.25, and

188 4.29). The peak value of DB query response is at 16.66 milliseconds, which is considerably lesser than that in dual stack (34.93 milliseconds), IP tunneling (34.711 milliseconds), and

IP NAT (34.991 milliseconds). The traffic volume is the same as that of the three models indicating fair comparisons.

Figure 5. 19: Database performance after completing the three phases of IPv6 transition controller application (Source: Researcher’s OPNET simulation results)

The video conferencing performance of the traffic controlled through the IPv6 transition controller application is presented in Figure 5.20 and is compared with Figures 4.22, 4.26, and 4.30. The initial peak of packet delay variation is about 0.859 milliseconds. From this peak, the packet delay variation dropped sharply to about 0.117 milliseconds and then gradually dropped 0.035 milliseconds (almost zero). Similar pattern was observed for video conferencing packet delay variation in dual stack, IP tunneling and IP NAT.

189

Figure 5. 20: Video performance after completing the three phases of IPv6 transition controller application (Source: Researcher’s OPNET simulation results)

The video conferencing end-to-end packet delay decreased sharply from a peak of 17.573 milliseconds to about 1.644 milliseconds and stabilized at this level. Similar pattern was observed in the three previous IPv6 transition models. Hence, it may be safely concluded that the video conferencing traffic controlled through the IPv6 transition controller application performed at par with the previous three models (dual stack, IP tunneling and

IP NAT). The video conferencing traffic volumes reached between 87.768 Mbps and

77.241610666667 Mbps in all the four design scenarios and hence, the comparisons made are fair.

190

Figure 5. 21: Voice performance after completing the three phases of IPv6 transition controller application (Source: Researcher’s OPNET simulation results)

Table 5. 2: The performance parameters comparison summary statistics against simulation time for dual stack, 6to4 tunneling, Network Address Translation transition schemes, and IPv6 transition controller application Simulation Time (sec) IPv6 Traffic Dropped (packets/sec) Transition Scheme 4m 0m 0s 0m 36s 1m 12s 1m 48s 2m 24s 3m 0s 3m 36s

12s

6.722222 - -

Tunneling 0 0 0 0 0

191

------

IPv6 IPv6 Controller App TCP Delay (sec) Transition 4m 0m 0s 0m 36s 1m 12s 1m 48s 2m 24s 3m 0s 3m 36s

Scheme 12s

- - - -

Tunneling 0.000455 0.000835 0.001073 0.001203

ntroll

- -

IPv6 IPv6 Co App er 0.000158 0.000531 0.000738 0.000712 0.000784 0.001058 TCP Segment Delay (sec) Transition 4m 0m 0s 0m 36s 1m 12s 1m 48s 2m 24s 3m 0s 3m 36s

Scheme 12s

- - - -

Tunneling 0.000069 0.000133 0.000153 0.000165

- -

IPv6 IPv6 Controller App 0.000054 0.000111 0.000143 0.000141 0.00016 0.000181 DB Query Response Time (sec) Transition 4m 0m 0s 0m 36s 1m 12s 1m 48s 2m 24s 3m 0s 3m 36s

Scheme 12s

- - - -

Tunneling 0.033509 0.034178 0.034545 0.034711

- -

IPv6 IPv6 Controller App 0.00474 0.016 0.01673 0.01555 0.01537 0.01666 DB Query Traffic Received (bytes/sec) Transition 4m 0m 0s 0m 36s 1m 12s 1m 48s 2m 24s 3m 0s 3m 36s Scheme 12s

192

556

- -

Tunneling 0 0 7,395.555 242,204.444444 219,093.333333 258,858.666667

.56

IPv6 IPv6 Controller App 0 0 1,123 233,159.11 216,960 216,163.56 243,384.89 271,985.78 DB Query Traffic Sent (bytes/sec) Transition 4m 0m 0s 0m 36s 1m 12s 1m 48s 2m 24s 3m 0s 3m 36s

Scheme 12s

ing

- -

Tunnel 0 0 7,395.555556 242,204.444444 219,093.333333 258,858.666667

ler ler

IPv6 IPv6 Control App 0 0 1,123.56 233,159.11 216,960 216,163.56 243,384.89 271,985.78 Video Conferencing Packet Delay Variation Transition 4m 0m 0s 0m 36s 1m 12s 1m 48s 2m 24s 3m 0s 3m 36s

Scheme 12s

- - - -

Tunneling 0.000096 0.000777 0.000065 0.000042

ntroller ntroller

- -

IPv6 IPv6 Co App 0.000805 0.000859 0.000117 0.000064 0.000045 0.000035 Video Conferencing Packet End-to-End Delay (sec) Transition 4m 0m 0s 0m 36s 1m 12s 1m 48s 2m 24s 3m 0s 3m 36s Scheme 12s

193

- - - -

Tunneling 0.006277 0.002331 0.002014 0.001913

644

- -

IPv6 IPv6 Controller App 0.017573 0.001563 0.001501 0.001628 0.001656 0.001 Video Conferencing Traffic Received (bytes/sec) Transition 4m 0m 0s 0m 36s 1m 12s 1m 48s 2m 24s 3m 0s 3m 36s

Scheme 12s

- -

Tunneling 0 0 21,120 58,905,600 72,771,840 77,238,720

98,720

IPv6 IPv6 Controller App 0 0 54,720 61,595,520 72,270,720 77,086,080 80,6 87,768,000 Video Conferencing Traffic Sent (bytes/sec) Transition 4m 0m 0s 0m 36s 1m 12s 1m 48s 2m 24s 3m 0s 3m 36s

Scheme 12s

- -

Tunneling 0 0 21,121.777778 58,909,559.1111 72,771,847.111111 77,241,610.666667

8.89

IPv6 IPv6 Controller App 0 0 55,68 61,597,552 72,268,807.11 77,089,928.89 80,698,567.11 87,768,000 Voice Jitter (sec) Transition 4m 0m 0s 0m 36s 1m 12s 1m 48s 2m 24s 3m 0s 3m 36s Scheme 12s

194

.000000521

0.000000311 0.000000050

- - - -

Tunneling 0 0.000000084 - -

0.000000147 0.000000064 0.000000263

- -

IPv6 IPv6 Controller App 0.000000005 - 0.000000227 - 0.000000034 - Voice MOS Value Transition 4m 0m 0s 0m 36s 1m 12s 1m 48s 2m 24s 3m 0s 3m 36s

Scheme 12s

- - -

Tunnelin - 2.517819300 2.517918703 2.517918703 2.517918703

er er

08078061

- -

IPv6 IPv6 Controll App 3.080691 3.08078061 3.08078061 3.08078061 3.08078061 3. Voice Packet Delay Variation Transition 4m 0m 0s 0m36s 1m 12s 1m 48s 2m 24s 3m 0s 3m 36s

Scheme 12s

- - - -

Tunneling 0 0.000000026 0.000000035 0.000000040

0052

- -

IPv6 IPv6 Controller App 0 0.000000017 0.000000024 0.000000029 0.000000043 0.00000 Voice Packet End-to-End Delay (sec) Transition 4m 0m 0s 0m 36s 1m 12s 1m 48s 2m 24s 3m 0s 3m 36s Scheme 12s

195

- - - -

Tunneling 0.100034885 0.100144073 0.100170904 0.100198920

Pv6 Pv6

- -

I Controller App 0.060044 0.06011545 0.060134424 0.060159949 0.06018521 0.060213991 Voice Traffic Received (bytes/sec) Transition 4m 0m 0s 0m 36s 1m 12s 1m 48s 2m 24s 3m 0s 3m 36s

Scheme 12s

- -

Tunneling 0 0 125.833333333 44,598.333333333 54,457.5 60,070

66666667

0,158.89

IPv6 IPv6 Controller App 0 0 113.3333 45,973.61 56,113.33 6 68,034.17 75,031.6 Voice Traffic Sent (bytes/sec) Transition 4m 0m 0s 0m 36s 1m 12s 1m 48s 2m 24s 3m 0s 3m 36s

Scheme 12s

4,458.333333333

- -

Tunneling 0 0 125.833333333 44,598.333333333 5 60,069.166666667

196

Controller Controller

3333

,158.89

IPv6 App 0 0 113. 45,973.61 56,113.33 60 68,034.17 75,031.666666667

Lastly, voice performance of the traffic controlled through the IPv6 transition controller application is presented in Figure 5.21 and is compared with Figures 4.23, 4.27, and 4.31.

There is a finite voice jitter and packet delay variation although the magnitude values are too small to be quantified. Hence, the tangible indicators are MOS value and end-to-end voice packet delay. The MOS and end-to-end voice packet delay are almost identical with the dual-stack model and IP NAT model (3.08078061 and 60.213991 milliseconds) but are noticeably better than the IP tunneling model (2.5 and 100.672 milliseconds). The maximum voice traffic was between 75.031666666667 Mbps and 57.5227777777778

Mbps in all the four models indicating a fair comparison.

It may be recalled that IP tunneling was found to be short of acceptable voice performance in the simulation of its voice traffic (Figure 4.27 and its analysis). However, IP tunneling has been used for data, voice, and video in the optimum design model controlled by the

IPv6 transition controller application and still has achieved the performance levels identical to dual stack and IP NAT. This change has happened because of introducing the IPv6 transition controller application and the ToS DB supporting it.

197 Based on the initial operations analysis and performance comparisons of data, voice, and video with dual stack, IP tunneling, and IP NAT designs, a critical analysis and summarization is presented in the next and concluding section of this chapter.

,5.4 Critical Analysis

In Section 4.4, the original design and modelling of the IPv6 transition controller application was presented. Further in Section 5.3, the simulation results were presented in two parts: simulation of the operations of the application (Sub-Section 5.3.1) and simulation results comparison of data, voice, and video performance with those of dual stack, IP tunneling, and IP NAT model designs (Sub-Section 5.3.1). Has the design of IPv6 transition controller application successfully achieved optimum performances of data, voice, and video communications? At this stage, it appears to be the case. The optimum choice for IPv6 transition is IP tunneling given that it employs the least of IPv4 addresses and is very easy to configure and manage. Also, the application has been successful in achieving results at par with dual stack and IP NAT although IP tunneling was found to return relatively inferior voice performance than the other two, as reflected in Figure 4.20.

However, the analysis of results of some of the recent studies tabulated in Table 4.4 revealed that the results of simulation in a single study cannot be taken as a benchmark for achieving empirical and optimal results, especially when there is an attempt to ratify a design. Those studies revealed that results obtained through simulations should only be accepted as indicators such that further studies can be conducted to investigate their reliability, validity, and conformability (to the real world networking and the experiences

198 of experts). Hence, in this section a brief analysis of reliability, validity, and conformability of the results is discussed before setting the ground for the next steps in this study.

Reliability: Reliability of a study reflects the consistency of findings if the same methods, techniques, tools, and environment is replicated by another research (Saunders, Lewis, &

Thornhill, 2009; Sekaran, 2003). This study is conducted using the academic edition of

OPNET Modeler, which is a recognized academic and professional network modelling and simulations software used extensively in advanced networking research (Dunaytsev, 2010;

Rahman, Pakstas, & Wang, 2009). In addition to recognized corporations and networking vendors, a large number of universities use OPNET for advanced networking education and research (Dunaytsev, 2010). It is affirmed that any researcher following the modelling process, traffic settings, node and link settings, choice of products, and application-level designs and advanced settings as defined in this study will be able to get comparable results.

However, this claim is limited to another academic study conducted by an academic researcher using OPNET. This claim cannot be extended to the practical networking systems solely by academic researchers because there is no point claiming confidence on the correctness and accuracy of a network simulation tool (even if it is popular) without inviting criticism and judgment by industry experts.

Validity: Validity of a research reflects the relevance of the variables and their measures used in the study such that the research may be perceived as having achieved outcomes based on standardised and trustworthy measures (Sekaran, 2003). In this study, the variables and their measures chosen for studying the performances of the four models, as presented in Sub-Section 4.3.1 are standard as per the networking literature. For example,

TCP delays and TCP segment delays are worldwide recognized measures for studying the

199 performance of TCP protocol in a network. Again, how OPNET might have handled these variables and their measures is subject to its reliability and industry wide acceptance.

Conformability: Conformability of a research depends upon three secondary variables: fitment to the subject area, creditability, and auditability (Malterud, 2001; Thompson &

Walker, 1998). Fitment to the subject area can be achieved by ensuring transferability of findings from the sample to the population studied with high credibility. Creditability can be established when interested users of the research can recognise the outcomes and relate with their experiences. Auditability of a research can be ensured by maintaining all records and documents created during the progress of the research such that they can be audited by the supervisor of the research and an external examiner.

5.5 Summary

Review of the three variables is indicating the need for evaluation of the design by industry experts. Input from experts is the only way to establish whether the IPv6 transition controller application is optimal or not. As per experience from comparison conducted in

Table 4.4, the outcomes may vary a bit in academic studies depending upon the experimentation environment, test bed, tools and techniques used, and such other variations. However, experts from industry can directly relate the design and its findings with their experiences and similar applications in action (if any). Keeping this projection in mind, a survey of networking experts was planned and executed using an online survey website. The survey was conducted using the instrument presented in Appendix D. Based on the survey, a series of quantitative analysis was done. The results are presented and analyzed in Chapter 6.

200 CHAPTER SIX

VALIDATION OF THE MODEL

6.1 Introduction

In this chapter, the reliability, validity, and conformability of the final design is tested with the help of statistical evaluation of the structural construct presented in Appendix D and described in Sub-section 3.7.2 is conducted. The data related with the construct is collected through an online survey. The questionnaire used for data collection is also presented in

Appendix D. The structural construct comprises of seven independent variables, four dependent variables, and three moderating variables. The data was collected in five levels as defined in Sub-section 3.7.2 for the independent and dependent variables. The variables and their levels were encoded as shown in Figure 6.1. The data was planned to be collected from Kenya and India, as shown in Figure 6.2. However, a third category “Other” was also defined such that respondents from other countries may also take the survey.

Figure 6. 1: Encoding of variables and defining their levels in SPSS

201

Figure 6. 2: Value labels set in SPSS for country of a respondent

The value labels of experiences of the respondents were configured as presented in Figure

6.3. Five different levels of experiences were defined. However, this is only for information and there is equal weighting given to all the respondents irrespective of their experiences.

Figure 6. 3: Value labels set in SPSS for number of years of experience of the respondents

The value labels of independent variables and moderators are presented in Figure 6.4. The five levels define different levels of practical validity of a variable. Figure 6.5 presents the value labels of the dependent variables.

202

Figure 6. 4: Value labels set in SPSS for the independent variables and the moderators

The dependent variables are defined in five levels as well. These levels define the magnitude of a variable. The structural construct maps the levels of practical validity of independent attributes with the magnitudes of dependent attributes, with the moderators varying the statistical significance of the relationships.

Figure 6. 5: Value labels set in SPSS for the dependent variables

203 The statistical tables of the survey data are presented in Section 6.2. Parts of the tables are presented in Appendix D.

6.2 Presentation of Survey Data

As presented in Table 6.1, there were 27 respondents from Kenya (34.6%) and 51 respondents from India (64.4%). The total number of respondents was 78. The survey was sent to 106 individuals through LinkedIn contacts. Hence, the response rate is 73.58%.

Table 6. 1: Frequency and percentages of the location of experience of the respondents Location of Experience Cumulative Frequency Percent Valid Percent Percent Valid Kenya 27 34.6 34.6 34.6 India 51 64.4 65.4 100.0 Total 78 100.0 100.0 Total 78 100.0

Table 6.2 presents the levels of experience of the respondents in TCP/IP networking. There were 37 respondents (47.4%) having experiences between one and less than three years,

27 respondents (34.6%) having experiences between three and less than five years, and 14 respondents (17.9%) having experiences between five and less than 10 years. Table 6.3 presents the descriptive statistics on levels of experiences of the networking experts. The mean is at 2.7 and standard deviation (SD) at 0.7578. There is a high positive skewness

(0.555), which means it has a steep downwards curve towards the higher level. The skewness of experience towards respondents with lesser experience is not clear from any literature (as far as searched). Perhaps, there is a greater number of networking experts with lesser experiences employed in Kenya and India than experts with higher experiences.

204 Also, it may be possible that experts with higher experiences are sufficient in number but could not find time to respond to the survey (it was a bit long with 14 questions).

Table 6. 2: Frequency and percentages of the number of years of experience in TCP/IP networking Number of years in TCP/IP Networking Cumulative Frequency Percent Valid Percent Percent Valid One year to less than 37 47.4 47.4 47.4 three years Three years to less than 27 34.6 34.6 82.1 five years Five years to less than 14 17.9 17.9 100.0 ten years Total 78 100.0 100.0 Total 78 100.0

The descriptive statistics of variables under consideration are presented in the next section for final analysis. Table 6.4 presents the model summary for the construct (presented in

Appendix D and discussed in Section 3.7.2) with and without moderators for dependent variable as Bandwidth performance (BANDP). As reviewed in Section 3.7.2, R indicates the correlation of multiple values of the dependent variable with the values of the independent variables, R squared represents the variation in values of a dependent variable, and Adjusted R squared represents adjustments as a result of change in number of variables

(Field, 2009; Peck & Devore, 2012).

205 Table 6. 3: Descriptive statistics for the number of years of experience in TCP/IP networking Descriptive Statistics Std. Minimu Maximu Deviatio N m m Mean n Skewness Kurtosis Std. Std. Statisti Statisti Statisti Erro Statisti Erro c Statistic Statistic c Statistic c r c r Number of 78 2.00 4.00 2.7051 .75780 .555 .272 -1.047 .538 years in TCP/IP networkin g Valid N 78

(listwise)

Table 6. 4: Multiple regression model summary for the construct with and without moderators for dependent variable as bandwidth performance (BANDP) Model Summary c Std. Error of the Model R R Square Adjusted R Square Estimate 1 .478a .229 .164 .61312 2 .519b .269 .173 .60991 a. Predictors: (Constant), Network Convergence: NETWC, Addressing Plan: ADDP, Physical Connectivity: PHYC, Routing Plan: ROUTP, Transition Mechanism: TRANS, Service Plan: SERVP b. Predictors: (Constant), Network Convergence: NETWC, Addressing Plan: ADDP, Physical Connectivity: PHYC, Routing Plan: ROUTP, Transition Mechanism: TRANS, Service Plan: SERVP, Implementation Cost: IMPLC, Hardware Compatibility: HARDC, Technical Expertise: TECHE c. Dependent Variable: Bandwidth Performance: BANDP

The model indicates slight increase in the R and R Squared values and reduction in

Adjusted R Squared value when moderators are implied upon the dependent variable

Bandwidth Performance (BANDP). This means that the regression slightly tends closer to a straight line after the moderators are applied. From Table G.1, it is found that there are two variables that have statistically significant relationships with bandwidth performance

(in 95% or more confidence interval): service plan (97.2% at 0.028 of non-confidence only)

206 and network convergence (100% confidence). The confidence on service plan improves slightly to 97.3% after the moderators are applied.

The ANOVA table of the construct for estimating F-statistic indicating the variations in

BANDP with respect to the independent variables (Field, 2009; Siegel, 2012) with and without the moderators is presented in Table 6.5. The F-statistic reduces when the moderators are applied. The confidence level on this reduction reduces from 99.6% to

99.2% (increase of non-confidence internal from 0.004 to 0.008), but it is still above 95%.

Hence, it appears that the overall variations of BANDP because of the independent variables have reduced after the moderators are applied.

Table 6. 5: ANOVA table of the construct with and without moderators for dependent variable as bandwidth performance (BANDP) ANOVAc Model Sum of Squares df Mean Square F Sig. 1 Regression 7.925 6 1.321 3.514 .004a Residual 26.690 71 .376 Total 34.615 77 2 Regression 9.320 9 1.036 2.784 .008b Residual 25.295 68 .372 Total 34.615 77 a. Predictors: (Constant), Network Convergence: NETWC, Addressing plan: ADDP, Physical connectivity: PHYC, Routing plan: ROUTP, Transition mechanism: TRANS, Service plan: SERVP b. Predictors: (Constant), Network Convergence: NETWC, Addressing Plan: ADDP, Physical Connectivity: PHYC, Routing Plan: ROUTP, Transition Mechanism: TRANS, Service Plan: SERVP, Implementation Cost: IMPLC, Hardware Compatibility: HARDC, Technical Expertise: TECHE c. Dependent Variable: Bandwidth Performance: BANDP

This ANOVA table does not provide an entire pictorial representation of the F-statistic.

This is because this table does not inform which independent variables are causing the variations in BANDP. Hence, the individual variations between the independent and dependent variables are reviewed from the MANOVA Tables H.1 and H.2. From Table

G.1, it is found that V5 (Service Plan: SERVP), V6 (Network Convergence: NETWC), and

207 V7 (Load Balancing: LOADB) have caused statistically significant variations in BANDP.

After the moderators are included the variable V5 is found to be causing much lesser statistically significant variances in BANDP (confidence reducing from 98.3%, to 95.5%), while the confidence in variances in the other two variables remain unchanged. Further,

V8 (hardware compatibility: HARDC) is also found to be causing variations in BANDP with confidence level of 97.3%. Thus, a moderator has taken away some share of influence on variations of BANDP from the independent variables.

Similar analysis is repeated for variations of the remaining three dependent variations. The observations are presented as the follows:

Observations in variations of throughput performance (THRP):

a) The regression tends considerably more towards a straight line when moderators

are applied to THRP. The statistically significant independent variable causing this

regression change is NETWC. The significance shifted from 94% to 99.9%.

b) The F-statistic reduces only slightly but the significance improved from 97.5% to

98.6% after applying the moderators.

c) The key influencing variables causing the variations in THRP are V6 (Network

Convergence) and V7 (Load Balancing) before applying the moderators and the

same after applying the moderators. However, the moderator V9 (Technical

Expertise) takes away some of the influence of the independent variables.

208 Table 6. 6: Multiple regression model summary for the construct with and without moderators for dependent variable as throughput performance (THRP) Model Summary c Std. Error of the Model R R Square Adjusted R Square Estimate 1 .423a .179 .110 1.02095 2 .501b .251 .152 .99636 a. Predictors: (Constant), Network Convergence: NETWC, Addressing Plan: ADDP, Physical Connectivity: PHYC, Routing Plan: ROUTP, Transition mechanism: TRANS, Service Plan: SERVP b. Predictors: (Constant), Network Convergence: NETWC, Addressing Plan: ADDP, Physical Connectivity: PHYC, Routing plan: ROUTP, Transition Mechanism: TRANS, Service plan: SERVP, Implementation Cost: IMPLC, Hardware Compatibility: HARDC, Technical Expertise: TECHE c. Dependent Variable: Throughput Performance: THRP

Table 6. 7: ANOVA table of the construct with and without moderators for Dependent Variable as Throughput performance (THRP) ANOVAc Model Sum of Squares df Mean Square F Sig. 1 Regression 16.148 6 2.691 2.582 .025a Residual 74.006 71 1.042 Total 90.154 77 2 Regression 22.648 9 2.516 2.535 .014b Residual 67.506 68 .993 Total 90.154 77 a. Predictors: (Constant), Network Convergence: NETWC, Addressing Plan: ADDP, Physical Connectivity: PHYC, Routing Plan: ROUTP, Transition Mechanism: TRANS, Service Plan: SERVP b. Predictors: (Constant), Network Convergence: NETWC, Addressing Plan: ADDP, Physical Connectivity: PHYC, Routing Plan: ROUTP, Transition Mechanism: TRANS, Service Plan: SERVP, Implementation Cost: IMPLC, Hardware Compatibility: HARDC, Technical Expertise: TECHE c. Dependent Variable: Throughput Performance: THRP

Observations in variations of Latency Performance (LATP):

a) The regression tends only slightly more towards a straight line when moderators

are applied to LATP. The statistically significant independent variables causing this

regression change are TRANS, SERVP, and NETWC. However, the significance

shifted from 100% to 99.9%, from 97.5% to 95.3%, and from 99.2% to 98.3%,

respectively.

209 b) The F-statistic reduces considerably and the significance reduced only marginally

from 99.9% to 99.8% after applying the moderators.

c) The key influencing variables causing the variations in LATP are V1 (Transition

Mechanism), V6 (Network Convergence), and V7 (Load Balancing) before

applying the moderators and V2 (Physical Connectivity), V6 (Network

Convergence), and V7 (Load Balancing) after applying the moderators. This is a

significant shift after applying the moderators. Further, it was observed that the

confidence level boosted considerably after applying the moderators. However, the

moderators V8 (Hardware Compatibility), V9 (Technical Expertise), and V10

(Implementation Cost) have taken away some of the influence of the independent

variables.

Table 6. 8: Multiple Regression Model Summary for the construct with and without moderators for Dependent Variable as Latency performance (LATP) Model Summary c Std. Error of the Model R R Square Adjusted R Square Estimate 1 .522a .273 .211 .62010 2 .551b .303 .211 .62014 a. Predictors: (Constant), Network Convergence: NETWC, Addressing Plan: ADDP, Physical Connectivity: PHYC, Routing Plan: ROUTP, Transition Mechanism: TRANS, Service Plan: SERVP b. Predictors: (Constant), Network Convergence: NETWC, Addressing Plan: ADDP, Physical Connectivity: PHYC, Routing Plan: ROUTP, Transition Mechanism: TRANS, Service Plan: SERVP, Implementation Cost: IMPLC, Hardware Compatibility: HARDC, Technical Expertise: TECHE c. Dependent Variable: Dependent Variable: Latency Performance: LATP

210 Table 6. 9: ANOVA table of the construct with and without moderators for dependent variable as latency performance (LATP) ANOVAc Model Sum of Squares df Mean Square F Sig. 1 Regression 10.238 6 1.706 4.437 .001a Residual 27.301 71 .385 Total 37.538 77 2 Regression 11.387 9 1.265 3.290 .002b Residual 26.151 68 .385 Total 37.538 77 a. Predictors: (Constant), Network Convergence: NETWC, Addressing Plan: ADDP, Physical Connectivity: PHYC, Routing Plan: ROUTP, Transition Mechanism: TRANS, Service Plan: SERVP b. Predictors: (Constant), Network Convergence: NETWC, Addressing Plan: ADDP, Physical Connectivity: PHYC, Routing Plan: ROUTP, Transition Mechanism: TRANS, Service Plan: SERVP, Implementation Cost: IMPLC, Hardware Compatibility: HARDC, Technical Expertise: TECHE c. Dependent Variable: Latency Performance: LATP

Observations in variations of Jitter Performance (JITTP): a) The regression tends considerably more towards a straight line when moderators

are applied to JITTP. The statistically significant independent variable causing this

regression change is TRANS. The significance shifted from 98.7% to 95.2%.

b) The F-statistic has improved significantly and the significance improved from

0.87% (statistically insignificant) to 96.3% after applying the moderators.

c) The key influencing variables causing the variations in JITTP are V1 (Transition

Mechanism), V3 (Addressing Plan), and V6 (Network Convergence) before

applying the moderators and only V1 and V6 after applying the moderators. This

is a significant shift after applying the moderators. Further, the moderator V10

(Implementation cost) takes away some of the influence of the independent

variables.

211 Table 6. 10: Multiple regression model summary for the construct with and without moderators for dependent variable as jitter performance (JITTP) Model Summary c Std. Error of the Model R R Square Adjusted R Square Estimate 1 .356a .127 .053 .77628 2 .470b .221 .118 .74910 a. Predictors: (Constant), Network Convergence: NETWC, Addressing Plan: ADDP, Physical Connectivity: PHYC, Routing Plan: ROUTP, Transition Mechanism: TRANS, Service Plan: SERVP b. Predictors: (Constant), Network Convergence: NETWC, Addressing Plan: ADDP, Physical Connectivity: PHYC, Routing Plan: ROUTP, Transition Mechanism: TRANS, Service Plan: SERVP, Implementation Cost: IMPLC, Hardware Compatibility: HARDC, Technical Expertise: TECHE c. Dependent Variable: Jitter performance: JITTP

Table 6. 11: ANOVA Table of the construct with and without moderators for dependent variable as jitter performance (JITTP) ANOVAc Model Sum of Squares df Mean Square F Sig. 1 Regression 6.202 6 1.034 1.715 .130a Residual 42.786 71 .603 Total 48.987 77 2 Regression 10.829 9 1.203 2.144 .037b Residual 38.158 68 .561 Total 48.987 77 a. Predictors: (Constant), Network Convergence: NETWC, Addressing Plan: ADDP, Physical Connectivity: PHYC, Routing Plan: ROUTP, Transition Mechanism: TRANS, Service Plan: SERVP b. Predictors: (Constant), Network Convergence: NETWC, Addressing Plan: ADDP, Physical Connectivity: PHYC, Routing Plan: ROUTP, Transition Mechanism: TRANS, Service Plan: SERVP, Implementation Cost: IMPLC, Hardware Compatibility: HARDC, Technical Expertise: TECHE c. Dependent Variable: Jitter Performance: JITTP

The observations made from statistical results in this section are analyzed in the next section. Based on the analysis, the overall findings of this study are discussed and summarised. Finally, the conclusions and recommendations are made in the final chapter of this study (Chapter 7).

212 6.3 Analysis of Survey Data and Discussions

Table 6.12 presents the descriptive statistics of all the variables in this construct. This table presents the mean, SD, skewness, and kurtosis of the independent and dependent variables, and the moderators. It is presented after the MANOVA and Multiple Regression analysis because it will now make sense for every significant relationship discovered. Now, the multiple regression and MANOVA outcomes are analyzed and discussed in the context of the descriptive statistics outcomes of the independent variables, the dependent variables, and the moderators.

Table 6. 12: Descriptive statistics for the independent variables, the moderators, and the dependent variables Descriptive Statistics Std. Minimu Maximu Deviatio N m m Mean n Skewness Kurtosis Std. Std. Statisti Statisti Statisti Erro Statisti Erro c Statistic Statistic c Statistic c r c r Transition 78 2.00 5.00 3.7692 .89621 -.189 .272 -.758 .538 mechanism: TRANS Physical 78 2.00 4.00 3.0897 .70593 -.128 .272 -.952 .538 connectivity: PHYC Addressing 78 3.00 5.00 3.5385 .55109 .322 .272 -.983 .538 plan: ADDP Routing plan: 78 4.00 5.00 4.3462 .47882 .660 .272 -1.607 .538 ROUTP Service plan: 78 2.00 4.00 3.3718 .56082 -.153 .272 -.789 .538 SERVP Network 78 1.00 4.00 2.0897 .77604 .013 .272 -.930 .538 Convergence: NETWC Load 78 3.00 4.00 3.7308 .44643 -1.061 .272 -.898 .538 Balancing: LOADB

213 Descriptive Statistics Std. Minimu Maximu Deviatio N m m Mean n Skewness Kurtosis Std. Std. Statisti Statisti Statisti Erro Statisti Erro c Statistic Statistic c Statistic c r c r Hardware 78 2.00 5.00 3.1282 .79542 .082 .272 -.750 .538 Compatibility: HARDC Technical 78 4.00 5.00 4.4872 .50307 .052 .272 -2.051 .538 Expertise: TECHE Implementatio 78 3.00 5.00 3.7308 .69643 .422 .272 -.861 .538 n Cost: IMPLC Bandwidth 78 2.00 4.00 2.6923 .67049 .452 .272 -.743 .538 Performance: BANDP Throughput 78 2.00 5.00 3.8462 1.08205 -.443 .272 -1.100 .538 Performance: THRP Latency 78 3.00 5.00 4.0769 .69822 -.106 .272 -.906 .538 Performance: LATP Jitter 78 3.00 5.00 4.0128 .79762 -.023 .272 -1.421 .538 Performance: JITTP Valid N 78

(listwise)

It is evident that the networking experts surveyed have viewed the final design very critically. The statistical modelling report presented in Section 6.2 has revealed different results for the four dependent variables, which are analyzed as follows:

a) Bandwidth Performance (BANDP): Variance in BANDP (mean 2.6923, SD 0.67)

is found to be statistically significantly influenced by service plan SERVP (mean

3.3718 SD 0.56), network convergence NETWC (mean 2.0897, SD 0.776), and

214 load balancing LOADB (mean 3.73, SD 0.446). Thus, good practical validity of

LOADB and SERVP and fair practical validity of NETWC in the final design are

expected to cause significant variations in BANDP at medium level. The experts

appear to be impressed with LOADB and SERVP of the final design but their

response reflect medium bandwidth performance on the network. The network

convergence is low (obviously) because the three forms of traffic (data, voice, and

video) are accessible through three independent network paths in the final design.

Confidence in service plan seems to be good because of inclusion of ToS DB in the

design. When the moderators are applied, only hardware compatibility (mean

3.1282, SD 0.7954) appeared to be influencing these relationships statistically

significantly. Hardware compatibility is rated as good in the final design by the

experts. The SD in all the variables is quite low indicating high consensus of the

mean values among the respondents. b) Throughput Performance (THRP): Variance in THRP (mean 3.8462, SD 1.082) is

found to be statistically significantly influenced by NETWC (mean 2.0897, SD

0.776) and LOADB (mean 3.73, SD 0.446). In spite of ToS DB in place, the experts

appear to be unconvinced about influence of service plan on throughput

performance. Perhaps, this is because the links have limited bandwidth in the final

design and may get overloaded when subscribers’ count increases. This anyways

can be improved when the ISPs increase the links capacities by adding more switch-

to-switch links. Interestingly, technical expertise (mean 4.48, SD 0.5) is rated as

excellent in the final design by the experts. They seem to be impressed with the

detailed technicalities and their practical feasibility in the final design. Further,

215 technical expertise is found to be a moderator for influencing throughput

performance. It appears they are seeking role of good technical experts in design

changes (like adding more switch-to-switch links) and network management. It

appears natural; technical experts will always support role of technical expertise.

One observation is that there is a high SD in THRP. This means that some of the

respondents deviated further from the mean, either above or below. This reflects

some differences in opinion although not significant enough to impact the outcome. c) Latency Performance (LATP): The experts appear to be highly critical about LATP

(mean 4.0769, SD 0.6982) as its variations are influenced by variations in transition

mechanism TRANS (mean 3.7692, SD 0.8962), NETWC (mean 2.0897, SD 0.776),

LOADB (mean 3.73, SD 0.446), and SERVP (mean 3.3718, SD 0.56) (from

regression analysis). Further, the moderators have a significant influence on LATP

as TRANS (mean 3.7692, SD 0.8962) is replaced by physical connectivity PHYC

(mean 3.0897, SD 0.7) and all the three moderators HARDC (mean 3.1282, SD

0.7954), TECHE (mean 4.48, SD 0.5), and IMPLC (mean 3.73, SD 0.696) have

induced statistically significant variations in LATP (mean 4.0769, SD 0.6982).

HARDC and TECHE indicates good choice of servers and switches and good

technical expertise influencing high latency performance (which is also reflected in

the final simulations). However, the experts also indicated between medium to high

implementation cost in achieving this design and the latency performance. Further,

replacement of TRANS by PHYC after applying the moderators is slightly

confusing. Perhaps, the experts want to give more weighting to physical

connectivity as against the IPv6 transition mechanism when the three moderators

216 are considered. Perhaps, this also implies more technical expertise to be hired

increasing the implementation cost because the current links capacities are

inadequate.

d) Jitter Performance (JITTP): JITTP (mean 4.0128, SD 0.7976) is found to be

statistically significantly influenced by TRANS (mean 3.7692, SD 0.8962), ADDP

(mean 3.5385, SD 0.5510), and NETWC (mean 2.0897, SD 0.776). This is the first

time ADDP has appeared as an influencing variable. However, statistical

significance of its influence reduces below 95% after IMPLC (mean 3.73, SD

0.696) takes over as a moderator, which is obvious because IMPLC will be very

nominal in this addressing scheme. IPv6 tunneling and the strategy of using IPv4

and IPv6 addresses were found to achieve good jitter performance in the final

simulations. The experts have rated jitter performance as excellent. This means that

the performance reported in this design has exceeded their expectations. The

situation may be poorer in real networks.

6.4 Summary

In this Chapter, Bandwidth performance is statistically significantly influenced by service plan, network convergence, and load balancing. The Throughput performance is found to be statistically significantly influenced by Network convergence and Load balancing. The

Latency performance is affected significantly by service plan, load balancing, network convergence, and transition mechanism while Jitter performance is found to be statistically significantly influenced by Transition mechanism, Addressing plan, and Network convergence. With the results of all simulations and statistical analysis completed, this

217 study can now be concluded. The next chapter presents the conclusions and generalisations of this study. It also presents recommendations for further studies related to this study.

218 CHAPTER SEVEN

RECOMMENDATIONS, FUTURE WORK & CONCLUSION

7.1 Summary of the Research

The networking industry is experiencing a shift towards IPv6 adoption amidst shortage of

IPv4 Internet addresses and increasing deployment of Internet-enabled devices (Internet of

Things) in addition to traditional computing through the Internet. However, a blanket solution of complete migration to IPv6 is not feasible since the Internet size and complexity together with millions of mission critical systems and Internet applications. The IP addressing is at the lowest level core design of the network. Any disruption in it can cause massive outages and business disruptions across the world.

Given this challenge, this study was conceptualised to design an optimal solution for coexistence of IPv4 and IPv6 addressing in current Internet-enabled networks operated by the Internet Service Providers (ISPs). There are three traditional designs for managing coexistence of IPv4 and IPv6 addresses: dual stack, IP 6to4 tunneling (or simply, IP

Tunneling), and network address translation. These designs were modelled and studied deeply in this study in the context of their performances. There were noticeable differences in the performances of these three designs. They seem to be feasible for different scenarios.

Specifically, IP tunneling was found as feasible for ISPs given the smallest number of IPv4 addresses needed, ease of deployment and management, and reasonably acceptable performance.

The dual-stack and NAT configurations reflected excellent performances on voice, data, and video. IP tunneling could match the performances in data and video but slightly lagged in voice performance, especially in jitters and packet delay variation, and the mean opinion

219 score returned. However, IP tunneling was also found to be recommended by recent studies as the most feasible and efficient design for coexistence of IPv4 and IPv6 addresses. NAT and dual stack designs were presented as most expensive and operationally complex, especially on ISP networks. The dual stack design did not make any sense at all because one needs to manage a pool of equal numbers of IPv4 and IPv6 addresses and simply make devices dual IP capable. This also shall add hardware cost significantly because many traditional hardware needs to be upgraded to support both the IP protocols. Hence, in the finalized custom design, the IP tunneling performance was enhanced by increasing the number of tunnels and allocating separate tunnels for data, voice, and video.

After modelling and simulating the three designs and comparing their performances, it was observed that they might be feasible in basic IPv6 routing through an IPv4 network but were not offering any quality of service and decision-making capabilities for the clients. In the modern networks, quality of service (and more recently, quality of experience) has gained attention as the data traffic has become complex and highly demanding amidst mixing of voice, video, and data in majority of modern applications. From the experience gained from OPNET modelling and simulations in this study, it was observed that the three designs for IPv6 co-deployment with IPv4 were not capable of ensuring definitions, decision-making, and operations for quality of service or quality of experience for clients accessing integrated or segregated multimedia applications. There were found as merely basic ways for ensuring coexistence of IPv4 and IPv6 addresses without any advanced capabilities.

220 With the discovery of this limitation, an optimal design for ensuring coexistence of IPv4 and IPv6 addresses with advanced traffic volume predictions, decision-making, and ensuring variable quality of service (for sustained quality of experience) was conceptualised. The basic technology chosen was IP tunneling as it was found to be most feasible among the three. The primary feasibility for selecting this technology was because it uses only one IPv4 address per tunnel through which, numerous IPv6 sessions can be passed through. The performance may be enhanced by allowing limited number of IPv6 sessions per tunnel and creating an optimal number of tunnels based on the switching and routing hardware capabilities and the available network bandwidth. There were three primary components designed in the form of an optimal application for making decisions in the IPv6 deployments: the IPv6 transition app, the IPv6 transition controller, and the type of service database (ToS DB). Further, to achieve the targeted optimality, the cloud servers were grouped and deployed separately as data servers, voice servers, and video servers. There were separate network paths defined to the three groups of servers. There were custom workflows defined within the IPv6 transition app, which were guided by the

ToS DB. The IPv6 transition controller is tasked to initiate and control the transitions based on quality of service levels defined in the ToS DB. These configurations were discussed in detail in Section 4.4 and hence, are not repeated here. In general, this enhanced performance application provided complex request-response interactions and decision- making or traffic routing based on quality of service levels defined in the ToS DB and destination preferences defined for different types of services with targeted quality of experiences.

221 The ToS DB was designed as a crucial component for the IPv6 transition application. In general, an ISP maintains massive metadata information about all the destination services, servers holding them, and client data with prescribed service levels. The ToS DB emulates the operations of such massive metadata information, which also gets continuously updated based on network changes, network dynamics, and preferences shifting of client devices requesting access to the applications. The IPv6 transition controller verifies the ToS status of every session in the running traffic and the metadata aspects of the subscribe requesting a new connection to a destination server. Based on an internal analysis, the traffic prioritization decision-making is conducted for all the new client requests. The connections with the highest priority shall be routed to the lowest loaded IPv6 tunnels whereas the connections with lowest priority shall be routed to the highest loaded IPv6 tunnels. The prioritization shall be defined based on the internal policies of the ISP (example, multiple tiers of paid Internet, and free Internet connections).

The performance testing of this application resulted in better performance than single IPv6 tunnel configuration tested for comparing it with dual stack and NAT. This application also performed comparable with dual stack and NAT designs. However, it should be noted that the design of the network has been modified to form multiple paths to dedicated server and hence the IP tunneling configuration performed much better than the single path configuration. It was realized that a conclusion about whether this design was optimum or not should not be taken based on simulation results only as there may be many practical configurations and events not reflecting in a simulation environment. Hence, a survey was conducted among networking experts in Kenya and India through Internet. The survey data

222 was analyzed through multiple regressions and descriptive statistical analysis. The key conclusions are presented in the next section.

7.2 Conclusions

The conclusions of this study have been drawn based on key findings from the survey analysis and analysing them in the context of experiences gained from the simulations. The conclusions drawn from the survey are from the evaluation and perspectives of the networking experts that have studied the design and its performance statistics generated in

OPNET’s simulation environment. The key conclusions are presented as follows:

a) In the developed design simulated in OPNET, bandwidth performance shall be

influenced significantly by service plan, network convergence, and load balancing

(among the IPv6 tunnels based on predictive prioritization, which is the key aspect

of the developed design). The networking experts were quite impressed with load

balancing and service planning of the final design, but their responses reflected that

bandwidth performance on the network needs to improve further. Subsequently,

they found the design to be low at network convergence as the three service types

are accessible through three different IPv6 tunnels. However, this is more of a trade-

off than a limitation because the IP tunneling performances for data, voice, and

video improved significantly at the cost of reducing network convergence. This

may not affect the client because the IPv6 transition controller senses the traffic

type and routes them to different IPv6 tunnels. Thus, the destination requests by a

mobile subscriber may be split and routed through multiple tunnels ensuring

optimum performances for all the traffic types.

223 b) The networking experts were not convinced about the throughput performance of

this design influencing service quality. This is because the network capacity in the

test bed modelling is much lower than that in the networks by real world ISPs. This

limitation may be overcome simply by investing in higher bandwidth links and

increasing their numbers on each of the switches. c) The networking experts treated technical expertise as a good moderator to improve

throughput performance. This reflects that they seek more technical thoughts to

improve the network capacity. d) The networking experts were very critical about latency performance of the design.

Their responses reflected that latency performance shall be affected significantly

by service planning, load balancing, network convergence, and transition

mechanism. They have tried to emphasize that compromising network convergence

at the cost of improved load balancing may result in varying latencies for different

service types. This may happen because there may be different loadings on different

IPv6 tunnels at the time of service requests. Hence, it is possible that a user may

experience excellent video performance but relatively lower performance of the file

transfer protocol (FTP). A general perception may be that H.264 protocol in MP4

streams has been prioritised over FTP. However, the real reason will be the

difference in loadings on the IPv6 tunnels leading to the two service destinations.

This will make service quality unpredictable if the design is not enhanced further.

This part is discussed in the next section on generalisations of the design in real

world networks.

224 e) The networking experts were highly impressed with the jitter performance. As

revealed in simulations of the single IPv6 tunnel configuration, the jitter

performance was poorer than the developed multi-tunnel design. Given that all the

results were shared with the experts, they have tried to communicate that they are

impressed with the multi-tunnel configuration and want more enhancements in load

balancing and network convergence. They have also projected a need for enhancing

physical connectivity, perhaps to ensure that the IPv6 tunnels are divided equally

among multiple parallel physical links. They have further reflected appreciation for

implementation cost as it proved to be a moderator in influencing jitter

performance. It needs to be noted that jitter performance is a very critical aspect as

voice requires real time traffic flow with high prioritization. Interactive voice

performance can only be achieved with quality of experience if it is awarded the

highest priority. In this design, the problem of such prioritization has been solved

as voice services can be reached through dedicated IPv6 tunnels, just like data and

video. Hence, the challenge is not in prioritizing voice traffic over data and video

albeit is to prioritize among multiple voice sessions running parallel.

With these conclusions, the generalisations possible on real world ISP networks are discussed in the next section.

7.3 Generalizations

In a real ISP network, the developed design will require multiple enhancements. The key enhancements reflected from the survey data review are: adding more physical links with higher bandwidths, adding design components dedicated for network traffic convergence before the stage where the responses from various services tend to converge at the client

225 device, and increasing the number of IPv6 tunnels for better load balancing. In real world networks, the ISPs may even consider allocating special IPv6 tunnels to various service providers of the same service type. For example, the ISPs may like to dedicate separate

IPv6 tunnels for YouTube and Vimeo depending upon the traffic demands and on the subscription levels. For example, Vimeo may be accessible with good performance through higher subscription levels only as it is known for streaming high quality and high definition videos only. There may be separate segregation of tunnels between different service categories. For example, movies on demand, news on demand, training/e-learning on demand, social media on demand, music on demand, file transfer on demand, multimedia and graphics applications on demand, two-person interactive voice, multi-person voice conferencing, two-person video conferencing, multi-person video conferencing, and many other such service categories may be accessible through their respective, separate, and dedicated IPv6 tunnels.

This study found that IPv6 tunneling is most feasible because just one IPv4 address can allow thousands of IPv6 sessions. However, it only appears to be good theoretically. The limits and boundaries need to be set very much cautiously as the experts have reflected in their responses. For example, the number of IPv6 sessions per IPv4 address needs to be limited depending upon the service type and category and the ongoing demands. This means that an ISP may have to implement thousands of IPv6 tunnels for enhanced load balancing and network convergence. The physical links have to be expanded accordingly, as well.

226 7.4 Recommendations for Further Research

This study has significant scope of future studies. The setting of the study test bed was moderate keeping in view the limitations faced by an academic researcher. However, the test bed can be enlarged significantly in future studies either by using professional edition tools of other simulators or by implementing test beds with real world networking and server equipment. In addition, experts from more countries should be invited to test or scrutinize test results from the larger test beds. In real world, there may be thousands of

IPv6 tunnels in action following the design and its principles developed in this study.

Hence, there is also a scope of artificial intelligence in predictive load analysis going much beyond advisory services of ToS databases. This aspect may also be examined in future research studies.

227 REFERENCES

Aazam, M., & Huh, E. (2014). Impact of IPv4-IPv6 Coexistence in Cloud Virtualization

Environment. Springer Annals of Telecommunications, 69(9), 485-496.

Ahmad, N., & Yaacob, A. (2012). IPSec over Heterogeneous IPv4 and IPv6 Networks:

Issues and Implementation. International Journal of Computer Networks &

Communications (IJCNC), 4(5), 57-72.

Ahmed, A. M., Mustafa, A. B., & Ibrahim, G. E. (2015). Performance Evaluation of IPv4

vs IPv6 and Tunneling Techniques Using Optimized Network Engineering Tools

(OPNET). IOSR Journal of Computer Engineering (IOSR-JCE), 4(1), 72-75.

Albkerat, A., & Issac, B. (2014). Analysis of IPv6 Transition Technologies. International

Journal of Computer Networks & Communications (IJCNC), 6(5), 19-38.

Ali, A. N. (2013). Comparison study between IPv4 and IPv6. International Journal of

Computer Science Issues (IJCSI), 9(3), 35-39.

Amogh, D. M. (2012). Measuring the Deployment of IPv6: Topology, Routing and

Performance. IMC, 1 - 14.

APNIC. (2015, January). IPv6 Measurements for the World. Asia-Pacific Network

Information Centre (APNIC). Retrieved March 20, 2016, from

http://labs.apnic.net/ipv6-measurement/Regions/001/

Arafat, M., Ahmed, F., & Sobhan, M. (2014). On the Migration of a Large Scale Network

from IPv4 to IPv6 Environment. International Journal of Computer Networks &

Communications (IJCNC), 6(2), 111-126.

Atkinson, R. (1995, August). RFC 1825: Security Architecture for the Internet Protocol.

Internet Engineering Task Force (IETF).

228 Babatunde, O., & Al-Debagy, O. (2014). A Comparative Review of Internet Protocol

Version 4 (IPv4) and Internet Protocol Version 6 (IPv6). International Journal of

Computer Trends and Technology (IJCTT), 13(1), 10-13.

Bahaman, E., Hamid, & Prabuwono, A. (2012). Network Performance evaluation of 6to4

tunneling. Innovation Management and Technology Research (ICIMTR), 263-

268.

Baker, F., Li, X., Bao, C., & Yin, K. (2011, April). RFC 6144: Framework for IPv4/IPv6

Translation. Internet Engineering Task Force (IETF)

Bi, J., Wu, J., & Leng, X. (2007). IPv4/IPv6 Transition Technologies and Univer6

Architecture. International Journal of Computer Science and Network Security,

7(1), 232-242.

Blanchet, M., & Parent, F. (2010, February). RFC 5572: IPv6 Tunnel Broker with the

Tunnel Setup Protocol (TSP). Internet Engineering Task Force (IETF)

Bradner, S., & Mankin, A., (1995, January). RFC 1752: The Recommendation for the IP

Next Generation Protocol. Internet Engineering Task Force (IETF)

Breslau, L., Estrin, D., Fall, K., Floyd, S., Heidemann, J., Helmy, A., Huang, P.,

McCanne, S., Varadhan, K., Xu, Y. & Yu, H. (2000). Advances in Network

Simulation. IEEE Computer 33(5), 59 - 67.

Carpenter, B., & Moore, K. (2001, February). RFC 3056: Connection of IPv6 domains

via IPv4 clouds. Internet Engineering Task Force (IETF).

Cerf, V., & Icahn, R. (2005). A protocol for packet network intercommunication. ACM

SIGCOMM Computer Communication Review, 71-82.

229 Chang, X. (1999). Network simulation with opnet. winter simulation conference, (pp.

307-314). Phoenix.

Chauhan, D., & S. S. (2014). A Survey on Next Generation Internet Protocol: IPv6.

International Journal of Electronics and Electrical Engineering, 2(2), 143-146.

Chen, J., Chang, Y., & Lin, C. (2004). Performance investigation of IPv4/IPv6 transition

Mechanisms. Proceedings of the 6th International Conference on Advanced

Communication Technology,, 545-550.

Chuangchunsong, N., Kamolphiwong, S., Kamolphiwong, T., Elz, R., & Pongpaibool, P.

(2014). Performance Evaluation of IPv4/IPv6 Transition Mechanisms: IPv4-in-

IPv6 Tunneling Techniques. In 2014 International Conference on Information

Networking (ICOIN), 10-12 Feb. 2014, Phuket, Thailand, 238-243, IEEE Xplore.

Cisco. (2004). Cisco IOS Network address translation. Retrieved May 12, 2016, from

CISCO:

http://www.cisco.com/en/US/technologies/tk648/tk361/tk438/technologies_white

_paper09186a0080091cb9.pdf

Cisco. (2010). Enterprise IPv6 Transition Strategy Using the Locator/ID Separation

Protocol. Cisco Systems White Paper. Retrieved 6 2, 2016, from

http://www.cisco.com/en/US/prod/collateral/.../white_paper_c11-629044.pdf

Cisco Systems. (n.d.). The ABC of IP Version 6. Retrieved May 5, 2016, from Cisco:

http://www.internetlivestats.com/internet-users/

Deering, S., & Hinden, R. (1998, December). RFC 2460: Internet Protocol, Version 6

(IPv6) Specification. Internet Engineering Task Force (IETF)

230 Delgrossi, L., & Berger, L. (1995, August). RFC 1819: Internet Stream Protocol Version

2 (ST2) Protocol Specification - Version ST2+. Internet Engineering Task Force

(IETF).

Dhole, V. S., & N. V. J. D. M. D. (2012). Data Security in the Transition from IPv4 to

IPv6. International Journal of Management, IT and Engineering, Vol.2(8), 194-

210.

Droms, R. (1997, March). RFC 2131: Dynamic Host Configuration Protocol. Internet

Engineering Task Force (IETF)

Dunaytsev, R. (2010). Network Simulators: OPNET Overview and Examples.

Department of Communications Engineering, Tampere University of Technology,

2-69.

Durand, A. (2001). Deploying ipv6. IEEE Internet Computing, 79-81.

Durand, A., Fasano, P., Guardini, I., & Lento, D. (2001, January). RFC 3053: IPv6

Tunnel Broker. Internet Engineering Task Force (IETF).

Dutta, P. M. G. P. S. S. S. C. (2012). Internet Protocols: IPv4 vis a vis IPv6. Asian

Journal of Information Technology, 11(3), 100-107.

Fantacci, R., Pecorella, T., & Habib, I. (2004). Evaluation of an Efficient Multiple-

Access Protocol for LEO Satellite Packet Networks. IEEE Journal on Selected

Areas in Communications, 22(3), 538-545.

Field, A. (2009). Discovering statistics using SPSS. London: Sage Publications.

Ford, M., Lew, H. K., Spanier, S., & Stevenson, T. (1999). Internetworking Technology

Overview. Cisco Systems, Inc.

231 Fuller, V., & Li, T. (2006, August). RFC 4632: Classless Inter-domain Routing (CIDR):

The Internet Address Assignment and Aggregation Plan. Internet Engineering

Task Force (IETF)

Gambhir, S., & Tomar, K. (2014). Study of Computer Network Issues and Improvising

Drop Rate of TCP Packets Using NS2. International Journal in Foundations of

Computer Science & Technology (IJFCST), 4(4), 85-98.

Ge., G. J., W., Me., & I., Wu., Y. (2014). The IPv6 Translation Mechanisms: Survey,

Evaluation Criteria and Deployment Considerations. Journal of Software, 4, 896-

912.

Georgescu, M., Hazeyama, H., Kadobayashi, Y., & Yamaguchi, S. (2014). Empirical

Analysis of IPv6 Transition Technologies using the IPv6 network evaluation

testbed. In Testbeds and Research Infrastructure: Development of Networks and

Communities, 137, 216-228. Springer International Publishing.

Georgescu, M., Hazeyama, H., Okuda, T., Kadobayashi, Y., & Yamaguchi, S. (2015).

Benchmarking the Load Scalability of IPv6 Transition Technologies: a Black-Box

Analysis. 20th IEEE Symposium on Computers and Communication (ISCC), 329-

334.

Guizani, M., Rayes, A., Khan, B., & Al-Fuqaha, A. (2010). Network Modeling and

Simulation: A Practical Perspective. United: John Wiley & Sons Ltd.

Golafshani. (2003, December). Understanding reliability and vallidity in qualitative

research. Toronto, Canada.

Govil, J., Govil, J., Kaur, N., & Kaur, H. (2008). An Examination of IPv4 and IPv6

Networks : Constraints and Various Transition Mechanisms. IEEE.

232 Graveman, R., Parthasarathy, M., Savola, P., & Tschofenig, H. (2007, May). RFC 4891:

Using IPsec to Secure IPv6-in-IPv4 Tunnels. Internet Engineering Task Force

(IETF)

Hinden, R., & Deering, S. (2003, April). RFC 3513: Internet Protocol Version 6 (IPv6)

Addressing Architecture. Internet Engineering Task Force (IETF)

Hinden, R., & Deering, S. (2006, February). RFC 4291: IP Version 6 Addressing

Architecture. Internet Engineering Task Force (IETF)

Holsti, O. R. (1969). Content analysis for the social sciences and humanities. Reading,

MA: Addison Wesley.

Hossain, A., Podder, D., Jahan, S., & Hussain, M. (2016). Performance Analysis of Three

Transition Mechanisms between IPv6 Network and IPv4 Network: Dual Stack,

Tunneling and Translation. International Journal of Computer (IJC), Vol. 20(1),

217-228.

Huitema, C. (2006, February). RFC 4380: Teredo: tunneling IPv6 over UDP through

Network Address Translations (NATs). Internet Engineering Task Force (IETF).

Huston, G. (2008, October). The Changing Foundation of the Internet: Confronting IPv4

Address Exhaustion. The ISP Column: A monthly column on things Internet.

Huston, G. (2015, January). IPv4 Address Report. Retrieved March 22, 2016, from

http://www.potaroo.net/tools/ipv4/.

Ibikunle, F., & A., O. B. (2011). Transition Techniques of the Future Internet Protocol -

IPv6. American Journal of Scientific Research (33).

IEEE-USA. (2009). Next Generation Internet: IPv4 Address Exhaustion , Mitigation

Strategies and Implications for the U.S. IEEE-USA White Paper.

233 Isaac, S., & Abdu, J. (2015). Comparative Analysis between IPv4 and IPv6. International

Journal of Information Systems and Engineering (IJISE), 20-24

ISOC. (2014, November 11th). Internet Issues. Retrieved from Internet Society:

http://www.isoc.org/internet/issues/ipv6_faq.shtml

Khadiri, K. E., Labouidya, O., Elkamoun, N., & Hilal, R. (2018). Performance

Evaluation of IPv4/IPv6 Transition Mechanisms for Real-Time Applications

using OPNET Modeler. International Journal of Advanced Computer Science and

Applications (IJACSA), Vol. (9)4, 387-392.

Khannah, B., & Alsadeh, A. (2017). Impact of IPv4/IPv6 Transition Techniques on

Applications Performance. 1-8, IEEE XPlore.

Komal. (2015). Performance Evaluation of Tunneling Mechanisms in IPv6 Transition: A

Detailed Review. 2015 Second International Conference on Advances in

Computing and Communication Engineering, 144-149.

Krikorian, R. (2016, May 05). What ever happened to IPv5? Retrieved from OReilly:

http://archive.oreilly.com/pub/post/what_ever_happened_to_ipv5.html

Krippendorff, K. (2004). Content Analysis: An Introduction to its Methodology (2nd ed.).

Thousand Oaks, CA: Sage publications

Krivokapic-skoko, B., & O’neill, G. (2014). Beyond the qualitative–quantitative

distinction: Some innovative methods for business and management research.

International Journal of Multiple Research Approaches. 5. 290-300.

10.5172/mra.2011.5.3.290.

234 Kumar, C. V., Venkatesh, K., Sagar, M. V., & Bagadi, K. P. (2016). Performance

Analysis of IPv4 to IPv6 Transition Methods. Indian Journal of Science and

Technology, 9(20), 1-8.

Ladid, L. (2009). IPv6-the next big bail-out: will IPv6 save the internet? In Proceedings

of the International Conference on Computer Systems and Technologies and

Workshop for PhD Students in Computing, 21-27.

Malterud, K. (2001). Qualitative research: standards, challenges, and guidelines. The

Lancet, Vol. 358, 483-488.

Mi, W., & Zhang, X. (2015). The Applicability Analysis of IPv6 Translation Transition

Mechanisms. International Journal Communications, Network and System

Sciences, 8, 62-69.

Mohammed, H., Adnan, H., & Hawraa, J. (2013). The Affects of Different Queuing

Algorithms within the Router on QoS VoIP Application using OPNET.

International Journal of Computer Networks & Communications, Vol. 5, 117-124.

Monte, C., Robles, M., Mercado, G., Taffernaberry, C., Orbiscay, M., & Tobar, S.

(2012). Implementation and Evaluation of Protocols Translating Methods for IPv4

to IPv6 Transition. Journal of Computer Science & Technology (JCS&T), 12(2),

4-70.

Narayan, S., & Tauch, S. (2010). Network Performance Evaluation of IPv4-v6

Configured Tunnel and 6to4 Transition Mechanisms on Windows Server

Operating Systems. In 2010 International Conference on Computer Design and

Applications (ICCDA), 25-27 June 2010, Qinhuangdao, Vol. 5, 435 - 440, China,

IEEE Xplore.

235 Narayan, S. & Tauch, S. (2010a). Network Performance Evaluation of IPv4-v6

Configured Tunnel and 6to4 Transition Mechanisms on Linux Operating Systems.

In 2010 2nd International Conference on Signal Processing Systems (ICSPS), 5-7

July 2010, Dalian, China, V2-113 - V5-117, China, IEEE Xplore.

Neuendorf, K. A. (2002). The Content Analysis Guidebook. Thousand Oaks, CA: Sage

Publications.

Nguyen, N. P., Anh, N. Q., Rantapuska, T., Utriainen, J., & Matilainen, M. (2012).

Transition From IPv4 To IPv6: A Method for Large Enterprise Networks. The

First International Conference on Communications, Computation, Networks and

Technologies, pp. 5-14. IARIA.

Nordmark, E., & Gilligan, R. (2005, October). RFC 4213: Basic Transition Mechanisms

for IPv6 Hosts and Routers. Internet Engineering Task Force (IETF)

Pan, J. & Jain, R. (2008). A survey of network si mulation tools: Current status and

future developments.

Partridge, C. (1995, June). Using the Flow Label Field in IPv6. Internet Engineering Task

Force (IETF).

Peck, R., & Devore, J. L. (2012). Statistics Exploration and Data Analysis (7th ed.). NY:

Cengage Learning.

Peng Wu, Y. C. M. X. J. D. C. M. (2011). Flexible integration of tunneling and

translation for IPv6 transition. Networking Science. Springer-Verlag Berlin

Heidelberg, Tsinghua University Press

Postel, J. (1981, September). RFC 791: Internet Protocol. Internet Engineering Task

Force (IETF).

236 Postel, J., & Reynolds, J. (1998, September). RFC 2400: Internet Official Protocol

Standards. Internet Engineering Task Force (IETF)

Rahman, M. A., Paktas, A., & Wang, F. Z. (2009). Network modelling and simulation

tools. Simulation Modelling Practice and Theory, Vol. 17, 1011 - 1031, Elsevier.

Rekhter, Y., & Li, T. (1996, October). RFC 2008: Implications of Various Address

Allocation Policies for Internet Routing. Internet Engineering Task Force (IETF)

Riverbed. (2016). OPNET is part part of Riverbed steelcentral; Get end-to-end

perpective of your application and network performance with OPNET

Technologies. Retrieved May 12, 2016, from Riverbed technologies.

Riverbed. (2017, December 13). Network Planning Simulation. Retrieved from Riverbed

Network Performance Management: http://www.riverbed.com/products-

solutions/products/network-performance- management/network-planning-

simulation/Network-Simulation.html

Sargent, R. G. (2004). Validation and verification of Simulation Models. Winter

Simulation Conference, 17-28.

Sarkar, N. I., & Halim, S. A. (2008). Simulation of Computer Networks: Simulators,

Methodologies and Recommendations. 5th International Conference on

Information Technology and Applications (ICITA), 420-425.

Saunders, M., Lewis, P., & Thornhill, A. (2009). Research methods for business students

(5th ed.). London: NY: Pearson.

Savita, S., & Monalisa. (2013). Comparison Analysis of Various Transition Mechanisms

from IPv4 to IPv6. International Journal Of Engineering And Computer Science,

2(6), 2006-2011.

237 Sekaran, U. (2003). Research Methods for Business: A Skill Building Approach (4th ed.).

NY: Wiley.

Shah, J. L. (2015, January). Next Generation Internet Protocol A Survey on Current

Issues and Mitigation. International Journal of Computer Science and Mobile

Computing, 4(1), 490 – 496. Retrieved from www.ijcsmc.com

Shah, J. L., & Parvez, J. (2014). Migration from IPv4 to IPv6: Security Issues and

Deployment Challenges. International Journal of Advanced Research in

Computer Science and Software Engineering, 373-376.

Shaneel, N., Salman, I., Avinesh, K., Ruchinav, G., & Khan, Z. (2016). Performance

Analysis of 4to6 and 6to4 Transition Mechanisms over Point to Point and IPSec

VPN Protocols. IEEE.

Shelly, G., & Vermaat, M. (2012). Discovering Computers: Your Interactive Guide to the

Digital World. United States of America: Course Technology, Cengage Learning.

Siegel, A. F. (2012). Practical Business Statistics (6th ed.). Worldwide: Elsevier.

Siraj, M. S., Gupta, A., & Rinku-Badgujar, M. (2012). Network Simulation Tools

Survey. International Journal of Advanced Research in Computer and

Communication Engineering (IJARCCE). 201-210

Srisuresh, P., & Egevang, K. (2001, January). RFC 3022: Traditional IP Network

Address Translator (Traditional NAT). Internet Engineering Task Force (IETF)

Stats, I. L. (2015). Internet Users in the World. Retrieved May 13, 2016, from Internet

live stats: http://www.internetlivestats.com/internet-users

Subramanian, S. (2003, November). IPv6 Transition strategies.

238 Templin, F., Gleeson, T., & Thaler, D. (2008, March). RFC 5214: Intra-site Automatic

Tunnel Addressing Protocol (ISATAP). Internet Engineering Task Force (IETF).

Thompson, C. B., & Walker, B. L. (1998). Basics of Research Part 12: Qualitative

Research. AM Journal, 17(2), 65-70.

Topolcic, C. (1990). Experimental Internet Stream Protocol: Version 2 (ST-II).

Wehrle, K., Gunes, M., & Gross, J. (2010). Modeling and Tools for Network Simulation.

10.1007/978-3-642-12331-3.

Wikipedia. (2016, May 4). Internet. Retrieved from Wikipedia, The free Encyclopedia:

http://www.wikipedia.org/

Wikipedia. (2016, February 5). Internet Stream Protocol. Retrieved from Wikipedia The

Free Encyclopedia: https://en.wikipedia.org/wiki/Internet_Stream_Protocol

Wu, P., Cui, Y., Wu, J., Liu, J., & Metz, C. (2013). Transition from IPv4 to IPv6: A state-

of-the-art survey. IEEE Communications Surveys & Tutorials, 15(3), 1407-1424.

Yagoub, G. Y. A., Mustafa, A. B. A., & Al-Gadi, A. Y. A. Y. (2014, August).

Comparison Between IPv4 and IPv6 Using OPNET Simulator. International

organization of Scientific Research Journal of Engineering (IOSRJEN), 4(8), 44-

50.

Yagoub, G. Y. A., Mustafa, A. B. A., & Hamied, A. M. (2014, August). Evaluation and

Comparisons of Migration Techniques from IPv4 To IPv6 Using GNS3

Simulator. International organization of Scientific Research Journal of

Engineering (IOSRJEN), 4(8), 51-57.

239 APPENDICES

Appendix A: List of RFCs

RFC 791 Internet Protocol. J. Postel. September 1981. (Format: TXT=97779 bytes)

(Obsoletes RFC 0760) (Updated by RFC 1349, RFC 2474, RFC 6864) (Also STD0005)

(Status: INTERNET STANDARD) (DOI: 10.17487/RFC 0791)

RFC 1190 Experimental Internet Stream Protocol: Version 2 (ST-II). C. Topolcic. October

1990. (Format: TXT=386909 bytes) (Obsoletes IEN119) (Obsoleted by RFC 1819)

(Status: EXPERIMENTAL) (DOI: 10.17487/RFC1190)

RFC 1752 The Recommendation for the IP Next Generation Protocol. S. Bradner, A.

Mankin. January 1995. (Format: TXT=127784 bytes) (Status: PROPOSED

STANDARD) (DOI: 10.17487/RFC1752)

RFC 1819 Internet Stream Protocol Version 2 (ST2) Protocol Specification - Version

ST2+. L. Delgrossi, Ed., L. Berger, Ed. August 1995. (Format: TXT=266875 bytes)

(Obsoletes RFC 1190, IEN119) (Status: HISTORIC) (DOI: 10.17487/RFC1819)

RFC 1825 Security Architecture for the Internet Protocol. R. Atkinson. August 1995.

(Format: TXT=56772 bytes) (Obsoleted by RFC 2401) (Status: PROPOSED

STANDARD) (DOI: 10.17487/RFC1825)

RFC 1958 Architectural Principles of the Internet. B. Carpenter, Ed. June 1996. (Format:

TXT=17345 bytes) (Updated by RFC 3439) (Status: INFORMATIONAL) (DOI:

10.17487/RFC1958)

RFC1933 Transition Mechanisms for IPv6 Hosts and Routers. R. Gilligan, E. Nordmark.

April 1996. (Format: TXT=47005 bytes) (Obsoleted by RFC2893) (Status:

PROPOSED STANDARD) (DOI: 10.17487/RFC1933)

240 RFC 2008 Implications of Various Address Allocation Policies for Internet Routing. Y.

Rekhter, T. Li. October 1996. (Format: TXT=34717 bytes) (Also BCP0007) (Status:

BEST CURRENT PRACTICE) (DOI: 10.17487/RFC2008)

RFC 2131 Dynamic Host Configuration Protocol. R. Droms. March 1997. (Format:

TXT=113738 bytes) (Obsoletes RFC 1541) (Updated by RFC 3396, RFC 4361, RFC

5494, RFC 6842) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC2131)

RFC 2400 Internet Official Protocol Standards. J. Postel, J. Reynolds. September 1998.

(Format: TXT=110969 bytes) (Obsoletes RFC 2300) (Obsoleted by RFC 2500) (Status:

HISTORIC) (DOI: 10.17487/RFC2400)

RFC 2460 Internet Protocol, Version 6 (IPv6) Specification. S. Deering, R. Hinden.

December 1998. (Format: TXT=85490 bytes) (Obsoletes RFC 1883) (Obsoleted by

RFC 8200) (Updated by RFC 5095, RFC 5722, RFC 5871, RFC 6437, RFC 6564, RFC

6935, RFC 6946, RFC 7045, RFC 7112) (Status: DRAFT STANDARD) (DOI:

10.17487/RFC2460)

RFC2893 Transition Mechanisms for IPv6 Hosts and Routers. R. Gilligan, E. Nordmark.

August 2000. (Format: TXT=62731 bytes) (Obsoletes RFC1933) (Obsoleted by

RFC4213) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2893)

RFC 3022 Traditional IP Network Address Translator (Traditional NAT). P. Srisuresh, K.

Egevang. January 2001. (Format: TXT=37675 bytes) (Obsoletes RFC 1631) (Status:

INFORMATIONAL) (DOI: 10.17487/RFC3022)

RFC 3053 IPv6 Tunnel Broker. A. Durand, P. Fasano, I. Guardini & D. Lento. January

2001. (Format: TXT=58575 bytes

241 RFC 3056 Connection of IPv6 Domains via IPv4 Clouds. B. Carpenter, K. Moore.

February 2001. (Format: TXT=54902 bytes) (Status: PROPOSED STANDARD)

(DOI: 10.17487/RFC3056)

RFC 3513 Internet Protocol Version 6 (IPv6) Addressing Architecture. R. Hinden, S.

Deering. April 2003. (Format: TXT=53920 bytes) (Obsoletes RFC 2373) (Obsoleted

by RFC 4291) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3513)

RFC3750 Unmanaged Networks IPv6 Transition Scenarios. C. Huitema, R. Austein, S.

Satapati, R. van der Pol. April 2004. (Format: TXT=48153 bytes) (Status:

INFORMATIONAL) (DOI: 10.17487/RFC3750)

RFC3904 Evaluation of IPv6 Transition Mechanisms for Unmanaged Networks. C.

Huitema, R. Austein, S. Satapati, R. van der Pol. September 2004. (Format:

TXT=46844 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3904)

RFC4029 Scenarios and Analysis for Introducing IPv6 into ISP Networks. M. Lind, V.

Ksinant, S. Park, A. Baudot, P. Savola. March 2005. (Format: TXT=64388 bytes)

(Status: INFORMATIONAL) (DOI: 10.17487/RFC4029)

RFC4038 Application Aspects of IPv6 Transition. M-K. Shin, Ed., Y-G. Hong, J. Hagino,

P. Savola, E. M. Castro. March 2005. (Format: TXT=69727 bytes) (Status:

INFORMATIONAL) (DOI: 10.17487/RFC4038)

RFC4057 IPv6 Enterprise Network Scenarios. J. Bound, Ed.. June 2005. (Format:

TXT=33454 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4057)

RFC 4213 Basic Transition Mechanisms for IPv6 Hosts and Routers. E. Nordmark, R.

Gilligan. October 2005. (Format: TXT=58575 bytes) (Obsoletes RFC 2893) (Status:

PROPOSED STANDARD) (DOI: 10.17487/RFC4213)

242 RFC4215 Analysis on IPv6 Transition in Third Generation Partnership Project (3GPP)

Networks. J. Wiljakka, Ed.. October 2005. (Format: TXT=52903 bytes) (Status:

INFORMATIONAL) (DOI: 10.17487/RFC4215)

RFC4241 A Model of IPv6/IPv4 Dual Stack Internet Access Service. Y. Shirasaki, S.

Miyakawa, T. Yamasaki, A. Takenouchi. December 2005. (Format: TXT=20580

bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4241)

RFC 4291 IP Version 6 Addressing Architecture. R. Hinden, S. Deering. February 2006.

(Format: TXT=52897 bytes) (Obsoletes RFC 3513) (Updated by RFC 5952, RFC

6052, RFC 7136, RFC7346, RFC 7371, RFC8064) (Status: DRAFT STANDARD)

(DOI: 10.17487/RFC4291)

RFC 4380 Teredo: Tunneling IPv6 over UDP through Network Address Translations

(NATs). C. Huitema. February 2006. (Format: TXT=132607 bytes) (Updated by

RFC5991, RFC 6081) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4380)

RFC 4632 Classless Inter-domain Routing (CIDR): The Internet Address Assignment and

Aggregation Plan. V. Fuller, T. Li. August 2006. (Format: TXT=66944 bytes)

(Obsoletes RFC 1519) (Also BCP0122) (Status: BEST CURRENT PRACTICE) (DOI:

10.17487/RFC4632)

RFC4727 Experimental Values In IPv4, IPv6, ICMPv4, ICMPv6, UDP, and TCP Headers.

B. Fenner. November 2006. (Format: TXT=19745 bytes) (Status: PROPOSED

STANDARD) (DOI: 10.17487/RFC4727)

RFC4779 ISP IPv6 Deployment Scenarios in Broadband Access Networks. S. Asadullah,

A. Ahmed, C. Popoviciu, P. Savola, J. Palet. January 2007. (Format: TXT=188511

bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4779)

243 RFC4852 IPv6 Enterprise Network Analysis - IP Layer 3 Focus. J. Bound, Y. Pouffary, S.

Klynsma, T. Chown, D. Green. April 2007. (Format: TXT=76199 bytes) (Status:

INFORMATIONAL) (DOI: 10.17487/RFC4852)

RFC 4891 Using IPsec to Secure IPv6-in-IPv4 Tunnels. R. Graveman, M. Parthasarathy,

P. Savola, H. Tschofenig. May 2007. (Format: TXT=46635 bytes) (Status:

INFORMATIONAL) (DOI: 10.17487/RFC4891)

RFC 5214 Intra-Site Automatic Tunnel Addressing Protocol (ISATAP). F. Templin, T.

Gleeson, D. Thaler. March 2008. (Format: TXT=30126 bytes) (Obsoletes RFC 4214)

(Status: INFORMATIONAL) (DOI: 10.17487/RFC5214)

RFC5569 IPv6 Rapid Deployment on IPv4 Infrastructures (6rd). R. Despres. January 2010.

(Format: TXT=21159 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5569)

RFC 5572 IPv6 Tunnel Broker with the Tunnel Setup Protocol (TSP). M. Blanchet, F.

Parent. February 2010. (Format: TXT=60017 bytes) (Status: EXPERIMENTAL)

(DOI: 10.17487/RFC5572)

RFC 6018 IPv4 and IPv6 Greynets. F. Baker, W. Harrop, G. Armitage. September 2010.

(Format: TXT=21541 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6018)

RFC 6036 Emerging Service Provider Scenarios for IPv6 Deployment. B. Carpenter, S.

Jiang. October 2010. (Format: TXT=45113 bytes) (Status: INFORMATIONAL) (DOI:

10.17487/RFC6036)

RFC 6127 IPv4 Run-Out and IPv4-IPv6 Co-Existence Scenarios. J. Arkko, M. Townsley.

May 2011. (Format: TXT=48227 bytes) (Status: INFORMATIONAL) (DOI:

10.17487/RFC6127)

244 RFC 6144 Framework for IPv4/IPv6 Translation. F. Baker, X. Li, C. Bao, K. Yin. April

2011. (Format: TXT=67181 bytes) (Status: INFORMATIONAL) (DOI:

10.17487/RFC6144)

RFC 6180 Guidelines for Using IPv6 Transition Mechanisms during IPv6 Deployment. J.

Arkko, F. Baker. May 2011. (Format: TXT=49679 bytes) (Status:

INFORMATIONAL) (DOI: 10.17487/RFC6180)

RFC 6219 The China Education and Research Network (CERNET) IVI Translation Design

and Deployment for the IPv4/IPv6 Coexistence and Transition. X. Li, C. Bao, M. Chen,

H. Zhang, J. Wu. May 2011. (Format: TXT=44774 bytes) (Status:

INFORMATIONAL) (DOI: 10.17487/RFC6219)

RFC 6343 Advisory Guidelines for 6to4 Deployment. B. Carpenter. August 2011. (Format:

TXT=51496 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6343)

RFC 6586 Experiences from an IPv6-Only Network. J. Arkko, A. Keranen. April 2012.

(Format: TXT=52062 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6586)

RFC 6589 Considerations for Transitioning Content to IPv6. J. Livingood. April 2012.

(Format: TXT=68822 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6589)

RFC 6883 IPv6 Guidance for Internet Content Providers and Application Service

Providers. B. Carpenter, S. Jiang. March 2013. (Format: TXT=60430 bytes) (Status:

INFORMATIONAL) (DOI: 10.17487/RFC6883)

RFC 6964 Operational Guidance for IPv6 Deployment in IPv4 Sites Using the Intra-Site

Automatic Tunnel Addressing Protocol (ISATAP). F. Templin. May 2013. (Format:

TXT=49568 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6964)

245 RFC 7040 Public IPv4-over-IPv6 Access Network. Y. Cui, J. Wu, P. Wu, O. Vautrin, Y.

Lee. November 2013. (Format: TXT=27273 bytes) (Status: INFORMATIONAL)

(DOI: 10.17487/RFC7040)

RFC 7059 A Comparison of IPv6-over-IPv4 Tunnel Mechanisms. S. Steffann, I. van

Beijnum, R. van Rein. November 2013. (Format: TXT=98886 bytes) (Status:

INFORMATIONAL) (DOI: 10.17487/RFC7059)

RFC 7381 Enterprise IPv6 Deployment Guidelines. K. Chittimaneni, T. Chown, L.

Howard, V. Kuarsingh, Y. Pouffary, E. Vyncke. October 2014. (Format: TXT=90299

bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7381)

RFC 8136 Additional Transition Functionality for IPv6. B. Carpenter, R. Hinden. 1 April

2017. (Format: TXT=13430 bytes) (Status: INFORMATIONAL) (DOI:

10.17487/RFC8136)

RFC 8219 Benchmarking Methodology for IPv6 Transition Technologies. M. Georgescu,

L. Pislaru, G. Lencse. August 2017. (Format: TXT=66085 bytes) (Status:

INFORMATIONAL) (DOI: 10.17487/RFC8219)

RFC 8250 IPv6 Performance and Diagnostic Metrics (PDM) Destination Option. N.

Elkins, R. Hamilton, M. Ackermann. September 2017. (Format: TXT=65231 bytes)

(Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8250)

246 Appendix B: Content Analysis Schedule

Table B. 1: Content analysis schedule

Internet Protocol Strategy Traffic Oriented Optimization ISPs IPv4 IPv Transition Model Tool Throughput Packet Latency Jitter 6 Mechanism Loss

247 Appendix C: Interview Schedule

1. Does your organization involve in the provision of internet services? (hosting, etc.)

2. How large is your current computer network? (Number of nodes such as computers,

users, servers, etc.)

3. Does your organization use both IPv4 and IPv6?

4. What are the main reasons for deploying IPv6 in the organization’s network?

5. What is the expected budget that your organization would be willing to spend for the

transition from IPv4 to IPv6?

6. Which factors initiated the IPv6 project?

7. What was the method of transition applied?

8. Are there any model(s) adapted or adopted for implementation?

9. Are there any problems experienced during the implementation process? If possible,

could you tell what they are?

10. Which factors are needed to prepare for the implementation?

11. If the implementation of IPv6 was successful, what is the most important factor? Are

there any advantages that the organization gets after deploying IPv6?

12. If the implementation failed, could you tell what the main reasons were? Will your

organization consider re-implementing IPv6?

13. Would you consider deploying IPv6 if there is a complete solution? What do you

expect from this solution?

248 Appendix D: Structured Questionnaire as the Survey Instrument

Independent Variables Dependent Variables

Bandwidth Transition Performance Mechanisms (6to4 Tunneling)

Throughput Performance Model

Latency Configuration Performance

Attributes (Physical Connectivity, Addressing Plan, Jitter Routing Plan, Service Performance Plan, Convergence, Load Balancing) Moderating Variables

▪ Hardware Compatibility

▪ Technical Expertise ▪ Cost of Implementation

Figure D. 1: The conceptual model

249

Figure D. 2: The developed model

These questions were presented to the survey respondents after sharing the details of the fourth model and its related application tool design details with them. The responses are in relation with how they view the level of practical validity of the independent variables, what is the level they perceive of the moderating variables, and what is the level of impact they view on the dependent variables.

Questions on the Independent Variables

Q1: In your view, what is the level of practical validity of the “transition mechanism” driven by the application tool?

Level 1: Poor (From 0 to 20% practical validity)

Level 2: Fair (From 21 to 40% practical validity)

Level 3: Good (From 41 to 60% practical validity)

250 Level 4: Excellent (From 61 to 80% practical validity)

Level 5: Outstanding (81 to 100% practical validity)

Q2: In your view, what is the level of practical validity of the “physical connectivity” of the ISP network for running the application tool?

Level 1: Poor (From 0 to 20% practical validity)

Level 2: Fair (From 21 to 40% practical validity)

Level 3: Good (From 41 to 60% practical validity)

Level 4: Excellent (From 61 to 80% practical validity)

Level 5: Outstanding (81 to 100% practical validity)

Q3: In your view, what is the level of practical validity of the “addressing plan” configured on the ISP network for running the application tool?

Level 1: Poor (From 0 to 20% practical validity)

Level 2: Fair (From 21 to 40% practical validity)

Level 3: Good (From 41 to 60% practical validity)

Level 4: Excellent (From 61 to 80% practical validity)

Level 5: Outstanding (81 to 100% practical validity)

Q4: In your view, what is the level of practical validity of the “routing plan” configured on the ISP network for running the application tool?

Level 1: Poor (From 0 to 20% practical validity)

Level 2: Fair (From 21 to 40% practical validity)

251 Level 3: Good (From 41 to 60% practical validity)

Level 4: Excellent (From 61 to 80% practical validity)

Level 5: Outstanding (81 to 100% practical validity)

Q5: In your view, what is the level of practical validity of the “service plan” configured on the ISP network for running the application tool?

Level 1: Poor (From 0 to 20% practical validity)

Level 2: Fair (From 21 to 40% practical validity)

Level 3: Good (From 41 to 60% practical validity)

Level 4: Excellent (From 61 to 80% practical validity)

Level 5: Outstanding (81 to 100% practical validity)

Q6: In your view, what is the level of practical validity of the “network convergence” configured on the ISP network for running the application tool?

Level 1: Poor (From 0 to 20% practical validity)

Level 2: Fair (From 21 to 40% practical validity)

Level 3: Good (From 41 to 60% practical validity)

Level 4: Excellent (From 61 to 80% practical validity)

Level 5: Outstanding (81 to 100% practical validity)

Q7: In your view, what is the level of practical validity of the “load balancing” configured on the ISP network for running the application tool?

Level 1: Poor (From 0 to 20% practical validity)

252 Level 2: Fair (From 21 to 40% practical validity)

Level 3: Good (From 41 to 60% practical validity)

Level 4: Excellent (From 61 to 80% practical validity)

Level 5: Outstanding (81 to 100% practical validity)

Questions on the Moderating Variables

Q8: In your view, what is the level of hardware compatibility needed for running the application tool?

Level 1: Very Low (From 0 to 20%)

Level 2: Low (From 21 to 40%)

Level 3: Medium (From 41 to 60%)

Level 4: High (From 61 to 80%)

Level 5: Very high (81 to 100%)

Q9: In your view, what is the level of technical expertise needed for running the application tool?

Level 1: Very Low (From 0 to 20%)

Level 2: Low (From 21 to 40%)

Level 3: Medium (From 41 to 60%)

Level 4: High (From 61 to 80%)

Level 5: Very high (81 to 100%)

253 Q10: In your view, what is the level of implementation cost needed for implementing and running the application tool?

Level 1: Very Low (From 0 to 20%)

Level 2: Low (From 21 to 40%)

Level 3: Medium (From 41 to 60%)

Level 4: High (From 61 to 80%)

Level 5: Very high (81 to 100%)

Questions on the Dependent Variables

Q11: In your view, what is the level of bandwidth performance (bandwidth utilization) that can be achieved by implementing and running the application tool?

Level 1: Very Low (From 0 to 20%)

Level 2: Low (From 21 to 40%)

Level 3: Medium (From 41 to 60%)

Level 4: High (From 61 to 80%)

Level 5: Very high (81 to 100%)

Q12: In your view, what is the level of throughput performance (bytes per second sent and received) that can be achieved by implementing and running the application tool?

Level 1: Very Low (From 0 to 20%)

Level 2: Low (From 21 to 40%)

Level 3: Medium (From 41 to 60%)

Level 4: High (From 61 to 80%)

254 Level 5: Very high (81 to 100%)

Q13: In your view, what is the level of latency performance (end-to-end packet delay) that can be achieved by implementing and running the application tool?

Level 1: Very Low (From 0 to 20%)

Level 2: Low (From 21 to 40%)

Level 3: Medium (From 41 to 60%)

Level 4: High (From 61 to 80%)

Level 5: Very high (81 to 100%)

Q14: In your view, what is the level of jitter performance (variations in delay of packets sent and received) that can be achieved by implementing and running the application tool?

Level 1: Very Low (From 0 to 20%)

Level 2: Low (From 21 to 40%)

Level 3: Medium (From 41 to 60%)

Level 4: High (From 61 to 80%)

Level 5: Very high (81 to 100%)

255 Appendix E: Multiple Regression Output Tables

Table E. 1: Multiple Regression Statistical Significance Table with and without moderators for Dependent Variable as bandwidth performance (BANDP)

Coefficientsa Standardized Unstandardized Coefficients Coefficients Model B Std. Error Beta t Sig. 1 (Constant) .380 1.049 .362 .719 Transition mechanism: TRANS .009 .085 .012 .103 .918 Physical connectivity: PHYC -.148 .114 -.156 -1.306 .196 Addressing plan: ADDP .245 .143 .202 1.713 .091 Routing plan: ROUTP -.036 .153 -.026 -.237 .813 Service plan: SERVP .362 .161 .302 2.241 .028 Network Convergence: NETWC .387 .096 .448 4.017 .000 2 (Constant) -.569 1.324 -.430 .669 Transition mechanism: TRANS .053 .090 .070 .583 .562 Physical connectivity: PHYC -.163 .114 -.172 -1.430 .157 Addressing plan: ADDP .235 .148 .194 1.592 .116 Routing plan: ROUTP .016 .159 .011 .099 .921 Service plan: SERVP .368 .163 .308 2.260 .027 Network Convergence: NETWC .380 .098 .440 3.892 .000 Hardware compatibility: HARDC -.030 .097 -.036 -.310 .757 Technical expertise: TECHE .256 .156 .192 1.645 .105 Implementation cost: IMPLC -.115 .104 -.119 -1.098 .276 a. Dependent Variable: Bandwidth performance: BANDP

Table E. 2: Multiple Regression Statistical Significance Table with and without moderators for Dependent Variable as throughput performance (THRP) Coefficientsa Standardized Unstandardized Coefficients Coefficients Model B Std. Error Beta t Sig. 1 (Constant) 6.263 1.747 3.584 .001 Transition mechanism: TRANS -.197 .142 -.164 -1.392 .168 Physical connectivity: PHYC .017 .189 .011 .092 .927 Addressing plan: ADDP -.103 .238 -.053 -.433 .666 Routing plan: ROUTP -.229 .254 -.101 -.901 .371 Service plan: SERVP .174 .269 .090 .648 .519 Network Convergence: NETWC -.456 .160 -.327 -2.844 .006 2 (Constant) 3.376 2.163 1.560 .123 Transition mechanism: TRANS -.188 .148 -.156 -1.272 .208 Physical connectivity: PHYC -.038 .186 -.025 -.204 .839

256 Coefficientsa Standardized Unstandardized Coefficients Coefficients Model B Std. Error Beta t Sig. Addressing plan: ADDP -.250 .242 -.127 -1.033 .305 Routing plan: ROUTP -.083 .260 -.037 -.320 .750 Service plan: SERVP .189 .266 .098 .709 .481 Network Convergence: NETWC -.536 .160 -.384 -3.357 .001 Hardware compatibility: HARDC .132 .159 .097 .829 .410 Technical expertise: TECHE .351 .255 .163 1.381 .172 Implementation cost: IMPLC .277 .171 .178 1.625 .109 a. Dependent Variable: Throughput performance: THRP

Table E. 3: Multiple Regression Statistical Significance Table with and without moderators for Dependent Variable as latency performance (LATP) Coefficientsa Standardized Unstandardized Coefficients Coefficients Model B Std. Error Beta t Sig. 1 (Constant) 3.317 1.061 3.126 .003 Transition mechanism: TRANS -.348 .086 -.447 -4.041 .000 Physical connectivity: PHYC .152 .115 .154 1.324 .190 Addressing plan: ADDP .147 .145 .116 1.015 .314 Routing plan: ROUTP -.168 .154 -.115 -1.086 .281 Service plan: SERVP .373 .163 .300 2.287 .025 Network Convergence: NETWC .264 .097 .294 2.712 .008 2 (Constant) 2.747 1.347 2.040 .045 Transition mechanism: TRANS -.305 .092 -.392 -3.320 .001 Physical connectivity: PHYC .138 .116 .140 1.194 .237 Addressing plan: ADDP .089 .150 .070 .592 .556 Routing plan: ROUTP -.163 .162 -.112 -1.007 .318 Service plan: SERVP .335 .166 .269 2.023 .047 Network Convergence: NETWC .244 .099 .271 2.455 .017 Hardware compatibility: HARDC -.116 .099 -.132 -1.170 .246 Technical expertise: TECHE .175 .158 .126 1.106 .273 Implementation cost: IMPLC .102 .106 .102 .964 .338 a. Dependent Variable: Latency performance: LATP

257 Table E. 4: Multiple Regression Statistical Significance Table with and without moderators for Dependent Variable as jitter performance (JITTP)

Coefficientsa Standardized Unstandardized Coefficients Coefficients Model B Std. Error Beta t Sig. 1 (Constant) 3.215 1.329 2.420 .018 Transition mechanism: TRANS .274 .108 .308 2.540 .013 Physical connectivity: PHYC -.146 .144 -.129 -1.016 .313 Addressing plan: ADDP .045 .181 .031 .251 .803 Routing plan: ROUTP -.102 .193 -.061 -.528 .599 Service plan: SERVP .132 .204 .093 .647 .520 Network Convergence: NETWC .026 .122 .025 .214 .831 2 (Constant) 2.933 1.627 1.803 .076 Transition mechanism: TRANS .224 .111 .251 2.012 .048 Physical connectivity: PHYC -.158 .140 -.139 -1.125 .264 Addressing plan: ADDP -.032 .182 -.022 -.176 .861 Routing plan: ROUTP -.099 .195 -.060 -.507 .614 Service plan: SERVP .121 .200 .085 .606 .546 Network Convergence: NETWC -.012 .120 -.012 -.099 .921 Hardware compatibility: HARDC .090 .119 .090 .754 .453 Technical expertise: TECHE -.151 .191 -.095 -.787 .434 Implementation cost: IMPLC .342 .128 .299 2.668 .010 a. Dependent Variable: Jitter performance: JITTP

258 Appendix F: MANOVA Output Tables

Table F. 1: MANOVA Table of independent and dependent variables without moderators

Tests of Between-Subjects Effects Type III Sum of Mean Source Dependent Variable Squares df Square F Sig. Corrected Model Jitter performance: JITTP 19.485a 13 1.499 3.251 .001 Latency performance: LATP 16.786b 13 1.291 3.982 .000 Throughput performance: THRP 27.366c 13 2.105 2.146 .023 Bandwidth performance: 13.555d 13 1.043 3.169 .001 BANDP Intercept Jitter performance: JITTP 122.303 1 122.303 265.314 .000 Latency performance: LATP 181.196 1 181.196 558.792 .000 Throughput performance: THRP 139.636 1 139.636 142.333 .000 Bandwidth performance: 82.760 1 82.760 251.502 .000 BANDP V1 Jitter performance: JITTP 9.394 3 3.131 6.793 .000 Latency performance: LATP 3.087 3 1.029 3.174 .030 Throughput performance: THRP 5.631 3 1.877 1.913 .136 Bandwidth performance: .686 3 .229 .694 .559 BANDP V2 Jitter performance: JITTP 2.622 2 1.311 2.844 .066 Latency performance: LATP 1.384 2 .692 2.133 .127 Throughput performance: THRP .051 2 .025 .026 .974 Bandwidth performance: 1.864 2 .932 2.833 .066 BANDP V3 Jitter performance: JITTP 2.324 1 2.324 5.041 .028 Latency performance: LATP .065 1 .065 .200 .656 Throughput performance: THRP .191 1 .191 .195 .660 Bandwidth performance: .289 1 .289 .879 .352 BANDP V4 Jitter performance: JITTP .390 1 .390 .846 .361 Latency performance: LATP .114 1 .114 .351 .556 Throughput performance: THRP .382 1 .382 .389 .535 Bandwidth performance: .107 1 .107 .325 .570 BANDP V5 Jitter performance: JITTP .537 1 .537 1.165 .284 Latency performance: LATP .340 1 .340 1.049 .310 Throughput performance: THRP .877 1 .877 .894 .348 Bandwidth performance: 1.968 1 1.968 5.981 .017 BANDP V6 Jitter performance: JITTP 5.429 2 2.714 5.888 .004 Latency performance: LATP 2.934 2 1.467 4.524 .015 Throughput performance: THRP 9.430 2 4.715 4.806 .011

259 Tests of Between-Subjects Effects Type III Sum of Mean Source Dependent Variable Squares df Square F Sig. Bandwidth performance: 6.031 2 3.016 9.165 .000 BANDP V7 Jitter performance: JITTP .037 1 .037 .079 .779 Latency performance: LATP 1.735 1 1.735 5.350 .024 Throughput performance: THRP 4.305 1 4.305 4.388 .040 Bandwidth performance: 2.122 1 2.122 6.448 .014 BANDP Error Jitter performance: JITTP 29.502 64 .461 Latency performance: LATP 20.753 64 .324 Throughput performance: THRP 62.788 64 .981 Bandwidth performance: 21.060 64 .329

BANDP Total Jitter performance: JITTP 1305.000 78 Latency performance: LATP 1334.000 78 Throughput performance: THRP 1244.000 78 Bandwidth performance: 600.000 78

BANDP Corrected Total Jitter performance: JITTP 48.987 77 Latency performance: LATP 37.538 77 Throughput performance: THRP 90.154 77 Bandwidth performance: 34.615 77

BANDP a. R Squared = .398 (Adjusted R Squared = .275) b. R Squared = .447 (Adjusted R Squared = .335) c. R Squared = .304 (Adjusted R Squared = .162) d. R Squared = .392 (Adjusted R Squared = .268)

Table F. 2: MANOVA Table of independent and dependent variables with moderators

Tests of Between-Subjects Effects Type III Sum of Mean Source Dependent Variable Squares df Square F Sig. Corrected Jitter performance: JITTP 21.220a 16 1.326 2.914 .001 Model Latency performance: LATP 20.971b 16 1.311 4.826 .000 Throughput performance: 32.725c 16 2.045 2.173 .016 THRP Bandwidth performance: 16.189d 16 1.012 3.350 .000 BANDP Intercept Jitter performance: JITTP 1.717 1 1.717 3.772 .057 Latency performance: LATP 14.886 1 14.886 54.806 .000 Throughput performance: .137 1 .137 .146 .704 THRP

260 Tests of Between-Subjects Effects Type III Sum of Mean Source Dependent Variable Squares df Square F Sig. Bandwidth performance: 4.126 1 4.126 13.660 .000 BANDP V1 Jitter performance: JITTP 6.869 3 2.290 5.030 .004 Latency performance: LATP 1.583 3 .528 1.943 .132 Throughput performance: 5.990 3 1.997 2.121 .107 THRP Bandwidth performance: .718 3 .239 .793 .503 BANDP V2 Jitter performance: JITTP 1.964 2 .982 2.157 .124 Latency performance: LATP 2.356 2 1.178 4.336 .017 Throughput performance: 1.654 2 .827 .879 .421 THRP Bandwidth performance: 1.519 2 .760 2.515 .089 BANDP V3 Jitter performance: JITTP .846 1 .846 1.858 .178 Latency performance: LATP .757 1 .757 2.788 .100 Throughput performance: 1.176 1 1.176 1.249 .268 THRP Bandwidth performance: 1.072 1 1.072 3.549 .064 BANDP V4 Jitter performance: JITTP .077 1 .077 .169 .682 Latency performance: LATP .363 1 .363 1.338 .252 Throughput performance: .243 1 .243 .258 .613 THRP Bandwidth performance: .058 1 .058 .193 .662 BANDP V5 Jitter performance: JITTP .200 1 .200 .440 .510 Latency performance: LATP .026 1 .026 .095 .759 Throughput performance: 2.203 1 2.203 2.340 .131 THRP Bandwidth performance: .756 1 .756 2.504 .119 BANDP V6 Jitter performance: JITTP 2.961 2 1.480 3.252 .045 Latency performance: LATP 4.570 2 2.285 8.413 .001 Throughput performance: 13.630 2 6.815 7.239 .002 THRP Bandwidth performance: 6.048 2 3.024 10.011 .000 BANDP V7 Jitter performance: JITTP .059 1 .059 .130 .720 Latency performance: LATP 5.531 1 5.531 20.366 .000 Throughput performance: .142 1 .142 .150 .700 THRP Bandwidth performance: 3.572 1 3.572 11.827 .001 BANDP

261 Tests of Between-Subjects Effects Type III Sum of Mean Source Dependent Variable Squares df Square F Sig. V8 Jitter performance: JITTP .078 1 .078 .171 .681 Latency performance: LATP 1.496 1 1.496 5.509 .022 Throughput performance: .020 1 .020 .022 .884 THRP Bandwidth performance: 1.543 1 1.543 5.108 .027 BANDP V9 Jitter performance: JITTP .053 1 .053 .116 .734 Latency performance: LATP 1.448 1 1.448 5.330 .024 Throughput performance: 3.571 1 3.571 3.793 .056 THRP Bandwidth performance: .031 1 .031 .103 .750 BANDP V10 Jitter performance: JITTP 1.397 1 1.397 3.070 .085 Latency performance: LATP 1.543 1 1.543 5.683 .020 Throughput performance: 3.190 1 3.190 3.388 .071 THRP Bandwidth performance: 1.090 1 1.090 3.608 .062 BANDP Error Jitter performance: JITTP 27.767 61 .455 Latency performance: LATP 16.568 61 .272 Throughput performance: 57.429 61 .941

THRP Bandwidth performance: 18.426 61 .302

BANDP Total Jitter performance: JITTP 1305.000 78 Latency performance: LATP 1334.000 78 Throughput performance: 1244.000 78

THRP Bandwidth performance: 600.000 78

BANDP Corrected Total Jitter performance: JITTP 48.987 77 Latency performance: LATP 37.538 77 Throughput performance: 90.154 77

THRP Bandwidth performance: 34.615 77

BANDP a. R Squared = .433 (Adjusted R Squared = .285) b. R Squared = .559 (Adjusted R Squared = .443) c. R Squared = .363 (Adjusted R Squared = .196) d. R Squared = .468 (Adjusted R Squared = .328)

262 Appendix G: Series of ITU-T Recommendations

Series A Organization of the work of ITU-T

Series B Means of expression: definitions, symbols, classification

Series C General telecommunication statistics

Series D General tariff principles

Series E Overall network operation, telephone service, service operation and human

factors

Series F Non-telephone telecommunication services

Series G Transmission systems and media, digital systems and networks

Series H Audiovisual and multimedia systems

Series I Integrated services digital network

Series J Cable networks and transmission of television, sound programme and other

multimedia signals

Series K Protection against interference

Series L Construction, installation and protection of cables and other elements of

outside plant

Series M Telecommunication management, including TMN and network

maintenance

Series N Maintenance: international sound programme and television transmission

circuits

Series O Specifications of measuring equipment

Series P Terminals and subjective and objective assessment methods

Series Q Switching and signaling

263 Series R Telegraph transmission

Series S Telegraph services terminal equipment

Series T Terminals for telematic services

Series U Telegraph switching

Series V Data communication over the telephone network

Series X Data networks, open system communications and security

Series Y Global information infrastructure, Internet protocol aspects and next-

generation networks

Series Z Languages and general software aspects for telecommunication systems

264 Appendix H: Publications

Barasa, S., Mbugua, S., & Karume, S. (2018). An Optimized Model for Transition from

IPv4 to IPv6 Networks in a Cloud Computing Environment, International Journal of

Computer Networks and Communications Security (IJCNCS), Vol. 6, Issue 8, ISSN: 2410-

0595, pp. 182 – 195 Paper Link: http://www.ijcncs.org/published/volume6/issue8/p3_6-

8.pdf.

Barasa, S., Mbugua, S., & Karume, S. (2018). Map of the Various Configuration Attributes from IPv4 to IPv6 Networks for Dual Stack, 6to4 Tunneling and NAT Modelling Designs in OPNET Modeler, International Journal of Computer Science and Mobile Computing

(IJCSMC), Vol. 7, Issue 7, ISSN: 2320–088X, pp. 32 – 44, Paper Link: http://ijcsmc.com/docs/papers/July2018/V717201806.pdf.

Barasa, S., Mbugua, S., & Karume, S. (2017). A survey of Transition Mechanisms and

Models for Transiting from IPv4 to IPv6 Networks, International Journal of Robotics and

Information Technology (IJRIT), Vol. 1, Issue 2, ISSN: 2001-5569, pp. 1 - 20, Paper Link: http://ijrit.net/papers/December2017/V1I201.pdf.

265 Appendix I: Research Authorization Permit

Figure I. 1: Research Authorization Permit

266 Appendix J: Research Permit

Figure J. 1: Research Permit

267 Appendix K: Research Grant Letter

Figure K. 1: Research Grant Letter

268