Embed Size (px)
Citation preview
Process for IPv6 Migration in Large Organizations
Pedro Filipe Martins de Castro
Dissertation submitted to obtain the Master Degree in
Communication Networks Engineering
Examination Committee
Chairperson: Prof. Paulo Jorge Pires FerreiraSupervisor: Prof. Ricardo Jorge Feliciano Lopes Pereira
Member of the Committee: Prof. Artur Miguel do Amaral Arsénio
October 2013
Abstract
The shortage of IP addresses has become the bottleneck for Internet development. IPv4 has no longer
the capacity to support the continuous growth of the Internet. For this reason, a new Internet protocol
was needed. However, the version 6 of the Internet protocol is not compatible with version 4, hence,
transition mechanisms must be used to ensure the transition from IPv4 to IPv6. Enterprises not prepared
for this transition will pay a high price. Since most of the enterprises around the globe have no IPv6
knowledge to create a decent road map towards IPv6, we present in this thesis a generic migration
process, which provides the necessary guidelines to reach a successful IPv6 migration. This process is
composed by 9 phases: analysis of the current situation, present a study focused on the migration impact
for the company, survey of the enterprise’s network, analyse IPv6 support from ISPs, estimate the costs
of migrating the company’s network, migration plan, testbed, identify problems and final implementation.
We then apply this process to a specific case.
Keywords: Migration, IPv6, Company, Plan, Process
i
Resumo
A falta de endereços IP tornou-se o maior entrave ao desenvolvimento da Internet. O IPv4 não tem
capacidade para permitir que a Internet continue a crescer como até aqui. Por esta razão foi necessário
criar uma nova versão do protocolo IP. No entanto, a versão 6 do protocolo IP não é compatível com a
versão 4, por isso, é necessário utilizar mecanismos de transição para a transição de IPv4 para IPv6.
As empresas que não estejam preparadas para esta transição vão pagar um custo elevado, uma vez
que a maior parte das empresas espalhadas pelo mundo não tem qualquer conhecimento sobre IPv6
para criar um plano para a introdução de IPv6 nas suas redes. Por esta razão, apresentamos nesta
tese um processo genérico para a migração de uma rede empresarial de IPv4 para IPv6. Este plano
é composto por 9 fases: análise da situação atual, estudo sobre o impacto da migração na empresa,
análise da rede da empresa, análise do suporte IPv6 por parte dos ISPs, estimativa dos custos para
migrar a rede da empresa, plano de migração, testbed, identificação de problemas e implementação
final. Após a definição deste plano, vamos aplicá-lo a um caso prático.
Palavras-Chave: Migração, IPv6, Empresa, Plano, Processo
iii
Acknowledgments
The realization of this thesis was only possible with the help of a numerous set of people who supported
me during the last year.
I want to express my gratitude to my supervisor, Prof. Ricardo Pereira, for his tremendous help and
support during the development of this work. I thank him for his availability, guidance and encouragement
over the whole year.
I am also grateful to both my co-advisors, Paulo Rio and Nassri Abokhalaf for their contribution for this
work. Their support and suggestions really helped me to improve my work.
I thank to Hewlett-Packard (HP) and Refer Telecom for giving me the opportunity to work on such a
fascinating theme. I also would like to thank to HP, for the paid internship.
I thank to Nuno Delgado from HP, who really helped me finding the right path to follow, when I was
starting my thesis.
I thank to my girlfriend Yesika Reinolds for always be there for me and for her endless support and
motivation.
For last but not least, I thank to my family, especially my mother Marcelina Castro, my father Manuel
Castro and my sister Ana Castro, for everything they do for me. Without their support I would not
achieve this goal.
v
Contents
Abstract i
Resumo iii
Acknowledgments v
1 Introduction 1
1.1 Contextualization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 Dissertation Layout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2 Background 5
2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2 IPv6 Advantages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.3 IPv6 Header . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.4 IPv6 Address Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.5 Domain Name System (DNS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.6 ICMPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.7 IPv6 Routing Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.8 Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.9 Migration Costs and Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3 State of the Art 15
3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
vii
3.2 IPv6 Worldwide . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.3 IPv6 in Portugal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.4 Transition Mechanisms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.4.1 Dual Stack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.4.2 Tunnelling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.4.3 Translation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.4.4 Evaluation of the Alternatives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
4 Methodology for the Migration Process 29
4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
4.2 Generic Migration Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
4.2.1 Anaysis of the Current Situation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
4.2.2 Present a Study Focused on the Migration Impact for the Company . . . . . . . . . 32
4.2.3 Survey of the Enterprise’s Network . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
4.2.4 Analyse IPv6 Capacity from ISPs . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
4.2.5 Estimate the Costs of Migrating the Company’s Network . . . . . . . . . . . . . . . 33
4.2.6 Migration Plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
4.2.7 Testbed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
4.2.8 Identify Problems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
4.2.9 Final Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
5 Practical Case 39
5.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
5.2 Analysis of the Current Situation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
5.3 Present a Study Focused on the Migration Impact for the Company . . . . . . . . . . . . 41
5.4 Survey of the Network Infrastructure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
5.5 Estimate the Costs of Migrating the Company’s Network . . . . . . . . . . . . . . . . . . . 45
5.5.1 Backup and Storage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
5.5.2 Virtualization and Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
viii
5.5.3 DNS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
5.5.4 Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
5.5.5 Linux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
5.5.6 Routers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
5.5.7 Firewalls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
5.5.8 Wireless . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
5.5.9 FaxMail and SMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
5.6 Migration Plan for Refer Telecom . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
5.6.1 Upgrading or Replacing Equipment Without IPv6 Support . . . . . . . . . . . . . . 56
5.6.2 Addressing Plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
5.6.3 Phased Deployment of IPv6 into the Network . . . . . . . . . . . . . . . . . . . . . 58
5.6.4 Treat Network’s Dependencies Without IPv6 . . . . . . . . . . . . . . . . . . . . . 61
5.6.5 Partial Decommissioning of IPv4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
5.6.6 Decommissioning of IPv4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
6 Experimental Validation 63
6.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
6.2 Validation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
6.2.1 IPv4 Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
6.2.2 IPv6 Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
6.2.3 Identification of Problems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
7 Conclusion 77
Bibliography 79
Appendix 83
A Configurations 83
A.1 Router Configuration Part 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
A.2 Router Configuration Part 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
ix
A.3 Vswitch VLANs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
B Firewall 87
B.1 IPv4 Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
B.2 IPv4 and IPv6 rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
C Data Protector 91
C.1 Successful backup to the web server over IPv6 . . . . . . . . . . . . . . . . . . . . . . . . 91
C.2 Data Protector switching from IPv6 to IPv4 . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
x
List of Tables
2.1 IPv6 Address Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.2 IPv6 Routing Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.3 Top10 IPv6 allocations by country . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.4 Top 20 countries with more percentage of ASes with IPv6 prefixes . . . . . . . . . . . . . 17
3.5 Companies with IPv6 prefixes in Portugal . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.6 Comparing the transition mechanisms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
5.7 Affected componenets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
5.8 Services and equipment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
5.9 Subnets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
6.10 VMs used . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
6.11 Different options to configure an IPv6 address in a host . . . . . . . . . . . . . . . . . . . 71
6.12 IPv4 vs IPv6 features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
xi
List of Figures
2.1 IPv4 and IPv6 header . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.2 Evolution of the percentage of ASes with IPv6 prefixes . . . . . . . . . . . . . . . . . . . . 17
3.3 IPv6 allocations in Portugal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.4 6to4 mechanism . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.5 Teredo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.6 DS-Lite mechanism . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.7 DNS64/NAT64 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.8 Transition Mechanisms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
5.9 Refer Telecom network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
5.10 Data centers network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
5.11 Data Protector . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
5.12 SMS per mail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
5.13 FaxMail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
5.14 Network to migrate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
5.15 IPv4/IPv6 addresses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
6.16 GNS topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
6.17 Switch configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
6.18 Implemented network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
6.19 DNS resolutions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
6.20 DHCP pools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
6.21 DHCPv6 messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
xiii
6.22 BIND forward lookup zone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
6.23 IPv6 enabled network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
A.24 Vswitch VLANs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
A.25 Vswitch VLANs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
A.26 Vswitch VLANs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
B.27 IPv4 firewall rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
B.28 Firewalls rules for a dual-stack network . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
C.29 Successful backup to the web server over IPv6 . . . . . . . . . . . . . . . . . . . . . . . . 92
C.30 Data Protector switching from IPv6 to IPv4 . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
xiv
List of Acronyms
ARP Address Resolution Protocol
ASes Autonomous Systems
ANACOM Autoridade Nacional de Comunicações
CGN Carrier-Grade NAT
CoS Class of Service
CIDR Classless Inter-Domain Routing
CPE Costumer-Premises Equipment
DMZ Demilitarized Zone
DoS Denial of Service
DDNS Dynamic DNS
DNS Domain Name System
DHCP Dynamic Host Configuration Protocol
DHCPv6 Dynamic Host Configuration Protocol version 6
EGP Exterior Gateway Protocols
FCCN Fundação para a Computação Científica Nacional
GPRS General Packet Radio Service
GSM Global System for Mobile Communications
GSM-R Global System for Mobile Communications - Railway
HP Hewlett-Packard
ICMP Internet Control Message Protocol
ICMPv6 Internet Control Message Protocol version 6
IGP Interior Gateway Protocols
IETF Internet Engineering Task Force
IHL Internet Header Length
xv
IP Internet Protocol
IPAM IP Address Management
IPv4 Internet Protocol version 4
IPv6 Internet Protocol version 6
ISP Internet Service Provider
ISATAP Intra-Site Automatic Tunnel Addressing Protocol
LIR Local Internet Register
MTU Maximum Transmission Unit
MIPv6 Mobile IPv6
MPLS Multi Protocol Label Switching
NDP Neighbor Discovery Protocol
NAT Network Address Translation
CNGI Next Generation Internet Project
NBMA Non-Broadcast Multiple Access
OS Operating System
PMTU Path Maximum Transmission Unit
PDH Plesiochronous Digital Hierarchy
QoS Quality of Service
RIR Regional Internet Register
RIPE NCC Reseaux IP Europeens Network Coordination Centre
RTT Round Trip Time
SMTP Simple Mail Transfer Protocol
SLAAC Stateless Address Autoconfiguration
SIIT Stateless IP/ICMP Translation
SDH Synchronous Digital Hierarchy
xvi
TTL Time to Live
TLD Top-Level Domain
TCP Transmission Control Protocol
ToS Type of Service
UMTS Universal Mobile Telecommunication System
UDP User Datagram Protocol
VM Virtual Machine
VoIP Voice over IP
WAN Wide Area Network
xvii
Chapter 1
Introduction
1.1 Contextualization
The growth of the Internet in the last two decades has shown the potential that the Internet has to
disclose and improve different areas such as education, businesses or entertainment. No one predicted
that World Wide Web would become by now a worldwide communication channel, so it was thought
that the number of addresses provided by the version 4 of the Internet Protocol was more than enough.
However, with the rapid development of new services, the rise of new business and the growing of
Internet users, Internet needs a larger address space. For this reason the Internet Engineering Task
Force (IETF) developed IPv6 in the mid 1990s. Since there was the need to create a new version of
the Internet Protocol to increase the address space, IETF took this opportunity to improve some of the
functionalities of IPv4, like routing efficiency, header format, Quality of Service (QoS), mobility, security
and auto-configuration [1]. With these changes IPv6 has the capacity to build a much more powerful
Internet.
Although IPv6 was standardized 17 years ago, its adoption is yet very limited [2]. This happened due
to the use of Classless Inter-Domain Routing (CIDR) and Network Address Translation (NAT), which
disguised the limitations of IPv4 in the last years. CIDR ended the huge waste of addresses caused by
the previous addressing architecture, which was based on classes. And NAT made possible the sharing
of the same IP address by different users, ending one of the Internet principals: every IP address must
be unique. However, NAT is not a perfect solution, quite the opposite. It has some drawbacks like
the break of end-to-end communications, its complexity and lack of scalability as well as reachability
problems.
With the depletion of IPv4 addresses in the Asia-Pacific region in the last year and now in Europe, IPv6
1
2 CHAPTER 1. INTRODUCTION
has become the best option to ensure the continuous growth of the Internet. If we look to concepts like
Internet of Things, intelligent houses or smart grids, which can take communications to a whole new
level, we realize that IPv4 can no longer respond to their demands. To allow the emergence of new
concepts like the ones presented, it is mandatory to proceed with the transition to IPv6. It is important to
realize that this transition will not happen from day to night. Instead IPv6 and IPv4 will operate in parallel
for many years as already happens. It is expected that the protocol takes at least one decade to spread
across the entire Internet [3]. Even after this time, some services may still be available through IPv4.
IPv6 will be the future of the Internet. With the depletion of IPv4 addresses, IPv6 migration is the only
feasible option to allow the continuous growth of the Internet. The question now is how much time
the transition will last. Many companies like Google, Facebook or Yahoo already gave the first step in
order to start this transition by providing their services through IPv6. It will be interesting to see how
organizations all around the globe are going to react to the imminent end of IPv4 addresses. Initiatives
like the one from the U.S Government, which is making an effort to have all its agencies web sites and
services available through IPv6 will put them far ahead of organizations and countries that are waiting to
see what will happen. Therefore migration mechanisms must be studied and analyzed by organizations
and governments to find the best approach to meet their needs. However, people are still very reluctant
to invest in IPv6 due to the huge investment needed, the lack of IPv6 knowledge and awareness and the
fact that NAT still gets the job done.
Sooner or later IPv6 will be present in every network around the globe, so, in order to minimize the costs
and to simplify the transition to IPv6, this thesis defines a generic migration process that can be used by
network administrators as a reference/guideline to introduce IPv6 in their networks. Then, we apply this
process to a small part of the Refer Telecom’s network. Thus, we will be able to validate our migration
process in a real scenario.
1.2 Dissertation Layout
This document describes the research and work developed and it is organized as follows:
• Chapter 2 provides a background on IPv6, identifying major changes and additions to IPv6 as well
as its benefits and problems
• Chapter 3 presents the state of the art for IPv6, showing its state worldwide and analyzing existing
transition mechanisms
• Chapter 4 describes the migration process elaborated
1.2. DISSERTATION LAYOUT 3
• Chapter 5 describes the implementation of the migration process in a subset of Refer Telecom’s
network
• Chapter 6 presents a simulation of a real migration for the subset of Refer Telecom’s network
• Chapter 7 summarizes the work developed and future work.
Chapter 2
Background
2.1 Introduction
The evolution of today’s networks to IPv6 in the next years is a fact. Due to the use of CIDR and NAT
the emergence of IPv6 was delayed more than expected. However now that the last IPv4 prefixes are
allocated both in Europe and in Asia, migration won an increased importance.
It is necessary to understand what is going to change with IPv6 and what kind of benefits it is bringing to
the world. Organizations around the world must be ready for this change as well as operating systems,
softwares and applications.
2.2 IPv6 Advantages
The following list contains some of the most important changes and additions introduced by IPv6 [4]:
Increased number of addresses - The major problem with IPv4 is the lack of address space. IPv6
eliminated this problem by proving an address space with a length of 128 bits instead of the 32 bits of
IPv4. Therefore, IPv6 addresses aren’t likely to exhaust in a foreseen future. With this improvement,
IPv6 solves the scalability issues present in IPv4.
Better support for Non-Unicast Addressing - IPv6 has a new kind of addressing: anycast. Anycast
addressing routes a packet to the nearest or more accessible member of a group where every node is
identified by the same destination address.
Multicasting has been improved and broadcast was withdrawn from IPv6 since this function could easily
overload a network.
5
6 CHAPTER 2. BACKGROUND
Renumbering - It is easier to renumber the IP addresses in networks and sub networks. It is also possible
to renumber a router address.
Auto configuration - IPv6 uses Stateless Address Autoconfiguration (SLAAC) [5], which enables a host
to automatically generate an IPv6 address when it is turned on. Using this address, called Link-Local
Address, a host can communicate within its local network without a Dynamic Host Configuration Protocol
(DHCP) server. If there is an IPv6 router, an IPv6 host within the local network can have a global unicast
address assigned by this router, automatically allowing access to the Internet. With SLAAC we can have
a "plug and play" network which means that a computer will have an IP address as soon as it connects
to the network.
Datagram Format - A new header format was created for IPv6 to make routing more efficiency. Section
2.2 analyses IPv6 header in detail.
QoS - The new header also has QoS related fields: traffic class and flow label. It allows classification of
packets.
Improved fragmentation - In IPv4, fragmentation was performed by the routers on the path between
the source and destination nodes. Now with IPv6 the fragmentation is performed by the source node
through the use of Internet Control Message Protocol version 6 (ICMPv6). This way the workload on
routers is reduced [6] because routers do not have to waste time analyzing the Maximum Transmission
Unit (MTU) in the link where they will send a packet and fragmenting it if necessary.
Mobility - In IPv6, mobility support is mandatory through the use of Mobile IPv6 (MIPv6). Through the
use of extension headers, which added powerful capabilities to Mobile IPv6 and its enormous address
space, IPv6 enhanced Mobile IP features. The following list [7] shows some of this improvements when
compared to Mobile IPv4:
• Route optimization is a built-in feature for Mobile IPv6, whereas in Mobile IPv4 it is added on as an
optional set of extensions that may not be supported by all nodes. This procedure helps to avoid
triangular routing.
• Address Auto-configuration and Neighbor Discovery allow mobile nodes to work in any location
without the need of special routers (foreign agents).
• Mobile IPv6 takes advantages of the IPv6 protocol itself. It uses the routing header instead of IP
encapsulation, therefore it reduces the overhead present in Mobile IPv4.
• In order to avoid the ingress-filtering problem present in Mobile IPv4, the correspondent node uses
the care-of address as the source address.
• Utilization of IPSec for all security requirements.
2.3. IPV6 HEADER 7
End-to-End communication - In IPv4 this semantics was lost due to the use of NAT. IPv6 brings back
end-to-end communications ensuring full network transparency. True end-to-end communication makes
it easier to maintain a network and may enable the appearance of new services [8].
Throughput - IPv6 can reach higher throughputs and a Round Trip Time (RTT) than IPv4 under the same
circumstances [9].
2.3 IPv6 Header
There were some significant changes in the IPv6 header when compared to the IPv4 header. IPv6
header was designed to: simplify the header format, thus reducing the header overhead [10], improve
routing efficiency and add QoS capabilities as well as authentication and privacy capabilities among
others [6].
It is important to realize that IPv4 and IPv6 are not interoperable; in fact the point of this thesis is to find
a way to disguise this lack of interoperability so we can have an operational network with both protocols.
When we look at both headers (Figure 2.1) we can see that the following fields were removed from IPv6
header: IHL, identifier, flag, fragment, header checksum and options. Less important information and
options field were moved in IPv6 header to the extension headers. This is what happens to the identifier,
flag and fragment fields, which are moved to the fragment extension header. Header checksum was
removed since, this function is provided by the upper layers [6].
In IPv6 header there are 5 new fields:
The traffic class, which provides Class of Service (CoS) support as Type of Service (ToS) field in IPv4
header does.
The flow label field allows labeling sequences of packets that require special treatment such as real-
time services.
The next header field, which identifies the type of header following the IPv6 header. The next header
can be either the Transmission Control Protocol (TCP) or User Datagram Protocol (UDP) header or an
extension header if provided.
Payload length, as the name states only defines the length of the payload whereas the total length field
in IPv4 header represents the total length of the packet including the header.
Time to Live (TTL) was renamed in IPv6 to Hop Limit so it can describe better its function, since a
packet don’t have "time to live" but a limited number of hops.
8 CHAPTER 2. BACKGROUND
Figure 2.1: IPv4 and IPv6 header
As already mention the source and destinations addresses fields now have 128 bits each instead of the
32 bits of IPv4.
IPv6 introduced also a new mechanism to replace the options field: extension headers. In order to
improve routing efficiency, when a packet is sent to its destination no one but the destination node
analyzes the extension headers in that packet. The only exception is the hop-by-hop extension, which
has to be analyzed by every router on its path. With this change, IPv6 reduces the processing load of
the routers when compared to IPv4, since with IPv4 every node on the network has to analyze the entire
IPv4 header resulting in processing overload. There are 6 different types of extension headers:
Hop-by-hop header - used to carry information that every node along its path must analyze.
Routing header - When a packet must visit predetermined nodes across its path, this header must be
used to specify which nodes to visit.
Destination header - used to carry additional information that can only be seen by the destination node
Fragment header - used when a package size is bigger than the Maximum MTU for that link. The
fragmentation of the packet occurs at the source node as opposed to IPv4 where the fragmentation is
performed by the routers along the packet delivery path.
Authentication header - used to provide message authentication and integrity
Encapsulating security payload header - this header provides message integrity and confidentiality.
2.4. IPV6 ADDRESS TYPES 9
2.4 IPv6 Address Types
Like in IPv4 there are rules for the attribution of addresses. There are addresses to be used on the
Internet (public addresses), addresses used on local networks and addresses reserved for different
usages. IETF is the entity in charge for this function. Table 2.1 contains the list of addresses types and
the respective network prefixes1.
Table 2.1: IPv6 Address Types
IPv6 notation is very different from the one used in IPv4. Instead of expressing the addresses in decimal
format as in IPv4, IPv6 expresses them in hexadecimal. The bits are grouped into groups of 16 bits and
are separated by ":". Although this notation is not very pleasant due to the extension of the addresses, it
is possible to compress zeros in order to make the writing of addresses easier. This syntax was created
because in IPv6 addresses, the appearance of long strings of zero bits is common. For example the
address:
2001:0d34:0000:0000:0000:0000:3653:62bc1https://www.ripe.net/lir-services/resource-management/allocations-and-assignments/
request-ipv6/ipv6addresstypes.pdf (last accessed October 1st, 2013)
10 CHAPTER 2. BACKGROUND
can be compressed to
2001:d34::3653:62bc
Regarding the text representation of address prefixes, these are written in CIDR just like in IPv4. Anyway,
even with the capability of compressing zeros, IPv6 addresses are not "user friendly". IPAM tools like
the ones from Blue Coat 1 and Infoblox 2 can be used to combat this problem since they automate and
simplify the management of IP addresses.
2.5 DNS
DNS is one of the main components of the Internet since it provides a way to resolve websites names
like www.ipv6.com into IP addresses. The guidelines that allow the DNS to handle IPv6 requests are
defined in RFC 3596 [11]. The way DNS handles IPv6 queries is very similar to the way it handles
queries in IPv4. Instead of using the A resource record type, DNS uses a new type of record for IPv6
- AAAA - which stores an IPv6 address. The main difference with the introduction of IPv6 is that, now
all the queries that were made for type A records have to be performed for type A and type AAAA. A
DNS server will always have to do this, since it has no way of knowing if the requesting node is using
IPv4 or IPv6. Nodes that implement dual stack must have a mechanism to choose which type of records
they will use in cases where both record types are found. However, most of the operating systems give
priority to IPv6 and only if the connection fails (timeout) IPv4 is used. This is a big problem because if
the IPv6 connection has issues the user will have an unnecessary delay in his connection. To solve this,
IETF published the Happy Eyeballs algorithm [12]. This algorithm performs both queries simultaneously
and uses the one that is returned first (IPv6 is still prefer). This way users do not have to disable IPv6
due to delays in the network.
It is also defined a special domain to look up a record corresponding to an IPv6 address. This provides
a way to map an IP address to a host name. The special domain is rooted at IP6.ARPA.
2.6 ICMPv6
Internet Control Message Protocol (ICMP) was modified for IPv6 in order to provide additional functions.
It still provides functions like ping and destination unreachable that were important in IPv4, but now
has new capabilities like Neighbor Discovery and Path Maximum Transmission Unit (PMTU). Neighbor
1http://www.ip-performance.co.uk/bluecatipambuiltright_15.php (last accessed October 1st, 2013)2http://www.infoblox.com/en/solutions/technology-solutions/ip-address-management.html (last ac-
cessed October 1st, 2013)
2.7. IPV6 ROUTING TYPES 11
Discovery Protocol (NDP) replaces the Address Resolution Protocol (ARP) and enhances it. It is respon-
sible for address auto-configuration of nodes, discovery of other nodes on the link, duplicate address
detection, finding available routers and DNS servers and removing the link-local broadcast traffic gener-
ated by ARP [13]. With these changes it also solves the problem of out dated ARP caches.
In IPv6 all links must support at least packets with 1280 bytes, but the minimum recommended is 1500,
whereas in IPv4 the MTU is only 576 bytes. This difference results in higher efficiency since there is
no need to process extra headers. Another advantage of PMTU is the fact that a source node uses
ICMPv6 to determine the PMTU in order to fragment the packet if needed. As already explained, in
IPv6, fragmentation can only be performed by the sources nodes, thus routing efficiency is increased.
Although ICMPv6 has new capabilities, which allow for greater network efficiency, it suffers from some
security problems [14] that must be dealt with.
2.7 IPv6 Routing Types
As in IPv4, IPv6 has 2 types of routing: static and dynamic. Static routing follows exactly the same
principles as in IPv4. Dynamic routing still has two types of protocols: Interior Gateway Protocols (IGP)
and Exterior Gateway Protocols (EGP) and as in IPv4 uses the longest-prefix match routing algorithm.
All the main routing protocols used in IPv4 have their own version for IPv6 (Table 2.2 ) [15].
Table 2.2: IPv6 Routing Protocols
2.8 Security
Most of the vulnerabilities present in IPv4 are still present in IPv6, furthermore, IPv6 brings new security
problems due to the changes made to IPv4. The following list shows some of these issues:
Extension headers - It is possible in IPv6 to create a chain of extension headers, meaning that an
attacker can manipulate an IPv6 header and point one extension header to another indefinitely because
there is no limit for the number of extension headers contained by an IPv6 header.
12 CHAPTER 2. BACKGROUND
Auto-configuration - SLAAC allows a node to get a global unicast address using ICMPv6 messages
without any approval. If an attacker can connect to a network using SLAAC, it is possible for him to send
router advertisements and respond to node solicitations, as well as performing Denial of Service (DoS)
attacks among others.
DNS Updates - With SLAAC all nodes are required to update DNS entries, not only the DHCP servers
as it happens in IPv4. This can introduce scalability problems for the Dynamic DNS (DDNS) security
mechanisms.
Multiple Addresses - In IPv6 an interface can have multiple addresses, therefore firewalls and access
control lists have a more complex job.
ICMPv6 - Since the use of ICMP in IPv4 was not essential, network administrators often blocked ICMP
messages to secure the network. However ICMPv6 is fundamental for IPv6. NDP, PMTU and SLAAC
use ICMPv6 massages for example. Thus, block ICMPv6 messages is no longer a solution, therefore it
must be handled differently.
Besides the issues present above, we must take into account the vulnerabilities caused by the use of
transition mechanisms. Additional mitigation measures are needed to guarantee network’s security.
2.9 Migration Costs and Benefits
With the transition to IPv6, organizations can enhance their business models in several ways. Network
management can became much easier for network administrators due to IPv6’s ability to configure itself;
therefore the costs of internal network management will be lower. Beyond that, new opportunities will
emerge, so we will have new ways of making money.
There are some aspects in IPv6 that can really change the way a enterprise works, for example the
mandatory support for mobility allows mobile teams to be constantly interconnected; the abundance of
IP addresses renders private addresses unnecessary, thus it is no longer necessary to manage NATs.
Although the elimination of NAT brings back the transparency of the networks, it plays an important
role on the security of users located behind a NAT box, since it is not possible for a machine to initiate
communication with a host located behind a NAT box. Therefore enterprises stop having a single entry
point for their network. However, the use of NAT is not the only way to achieve this, proxies can be use
with the same purpose.
IPv6 can facilitate the "Internet of Things" emergence[8]. This concept refers to a network interconnect-
ing common objects equipped with intelligence modules, so it is not possible for "Internet of Things" to
grow within an IPv4 network due to its lack of address space and scalability.
2.9. MIGRATION COSTS AND BENEFITS 13
Many economic sectors could profit with IPv6 adoption like: entertainment, leisure, gaming, transporta-
tion, health care and education [8].
IPv6 can also facilitate the emergence of smart grids, which use information and communications tech-
nology in an automated manner to allow communication schemes for monitoring and managing the
generation, transmission and distribution of electricity. Finally, IPv6 can allow the appearance in higher
numbers of intelligent houses, since these houses require a considerable number of addresses to inter-
connect all the devices in them.
The benefits that IPv6 can bring to this sectors are obvious. So, what is holding back the migration?
Here are some of the main reasons:
• The huge investment needed to upgrade existent equipment or acquire new equipment with IPv6
capacity;
• Compatibility problems between the two protocols;
• NAT;
• The experience with this new protocol is limited;
• Some security problem may arise;
• Must exist an interoperability with hardware and software used;
• The business return on such an investment is uncertain.
Even if enterprises do not want to spend time and money to make their services available through IPv6
right now, they should at least prepare for this scenario. There will be costs for companies that do not
prepare themselves for IPv6:
• By being reactive instead of proactive the costs with the transition will be much higher because
there will be no time to prepare a proper migration plan.
• If a company that is already planning the migration has to buy new equipment and services, they
can ensure that the equipment bought is compatible with IPv6. Other companies may waste money
on equipment that must be replaced in a couple of years because they do not have IPv6 support.
• With the exhaustion of IP addresses in Asia, IPv6 is the only solution to allow new users in that
area to access the Internet. Therefore, exists here, a new market waiting to be explored.
• Companies not prepared for IPv6 can hurt their reputation if their rivals are already prepared for
IPv6. For example if a service is made available through IPv6 and Company A cannot provide this
14 CHAPTER 2. BACKGROUND
service, because they did not prepare themselves for IPv6, they may loose clients to companies
that already support IPv6.
Chapter 3
State of the Art
3.1 Introduction
People and companies around the world already realized that IPv6 will be the future of modern Internet.
In this section we try to show the state of IPv6 worldwide and analyze the existing transition mechanisms
to better understand how they can facilitate the transition to IPv6.
3.2 IPv6 Worldwide
People and companies around the world already realized that IPv6 will be the future of modern Internet.
We can see that by the number of acquired IPv6 prefixes worldwide. United States is the country with
most IPv6 prefixes (3233), this is explain by 2 factors: the first one is its size when compared to other
countries, but the most important one is related with the demand of U.S. government to assure that all
federal agencies should had their services available through IPv6 until September 2012 [16]. Although,
only 11% of U.S federal agencies fulfilled this deadline, whereas 54% showed no progress in IPv6
adoption. By the time of this writing IPv6 enabled domains had increased to 25% while IPv6 services
are already supported by 45% of agencies 1. It is expected by the U.S government that in 2014 all
agencies will be fully IPv6 operational and able to communicate with external networks using IPv6 [16].
With this measures, U.S government contributed decisively for the United States position in this ranking.
The 2 countries that complete the Top 3 are Brazil and Germany with 1207 and 889 IPv6 allocations
respectively. Table 3.3 provides the Top 10 countries with more IPv6 allocations 2.
1http://fedv6-deployment.antd.nist.gov/snap-all.html (last accessed October 1st, 2013)2http://www.ipv6actnow.org/info/statistics/allocations-and-assignments/ (last accessed October 1st,
2013)
15
16 CHAPTER 3. STATE OF THE ART
Table 3.3: Top10 IPv6 allocations by country
Governments from countries like Australia [17] and China are also decided to take advantage of early
IPv6 deployment. China for example has a five-year plan called Next Generation Internet Project (CNGI)
that aims to have a prominent position in IPv6 network. This plan started in 2008 at the Olympics in
Beijing where China used IPv6 to transmit and manage the competition [16].
Nowadays the number of Local Internet Registers (LIRs) with IPv6 allocations is above 6100, and already
surpassed the number of LIRs without IPv6 (slightly above 3400) 1 in the Reseaux IP Europeens Network
Coordination Centre (RIPE NCC) service region. By default Regional Internet Registers (RIRs) assign
/32 prefixes to LIRs. LIRs for their turn assign by default a /48 to their clients [18]. These values can be
changed to better adjust to each case.
Looking at the data provided by RIPE NCC 2 about the adoption of IPv6 in Autonomous Systems (ASes)
all around the world, it is possible to assume that organizations realized that IPv6 cannot be delayed
much longer. A large number of ASes already took the first step towards migration by acquiring at least
one IPv6 prefix. In Norway the percentage of ASes with at least one IPv6 prefix attributed is 58,75%
already, which corresponds to 94 ASes from a total of 160. The second country in this list is Netherlands,
where 48,26% of ASes in the country have at least one IPv6 prefix. The Top 20 countries with the higher
percentage of ASes with IPv6 prefixes are present in Table 3.4. In the top 10 there are 7 countries from
RIPE NCC region, which shows that Europe is one step ahead when compared to the rest of the world.
IPv6 is available for more than a decade, but only in 2009 was possible to notice a significant increase
in the allocation of addresses in the ASes worldwide. Looking at Figure 3.2 we can verify that from
2004 to 2009 the percentage of ASes with IPv6 prefixes increased from 2.37% to 4% only. However
from 2009 to September of 2013 this percentage raised from 4% to 16.62%. As we can see the trend is
for the percentage of ASes with IPv6 prefixes to keep growing in the next years, and this tendency will
probably increase now that Asia and Europe regions exhausted their address spaces.
1https://labs.ripe.net/statistics-information/ipv6members1210.png (last accessed October 1st, 2013)2http://v6asns.ripe.net/v/6?s=_ALL;s=NO;s=NL;s=MY;s=JP;s=SE;s=DE (last accessed October 1st, 2013)
3.2. IPV6 WORLDWIDE 17
Table 3.4: Top 20 countries with more percentage of ASes with IPv6 prefixes
Figure 3.2: Evolution of the percentage of ASes with IPv6 prefixes
18 CHAPTER 3. STATE OF THE ART
Internet has 318 Top-Level Domains (TLDs). By September of 2013, 263(89%) supported IPv6 access
to their domain name servers. If we look at the data provided by RIPE about K-root 1, one of the 13
Root Name Servers of the Internet, there are about 1000 queries/s from IPv6 nodes and about 16000
queries/s from IPv4 nodes. The number of queries almost quadruple in just two year, representing now
6,25 % of the total queries in this DNS server. If we now look at the data from reverse DNS servers 2,
we can see that 48.9% are reachable via IPv6. The same data shows us that the percentage of reverse
DNS servers where IPv6 is as fast or faster than IPv4 is 78,4%.
To have a better perception of IPv6 availability let’s check the top 1000000 accessed sites over the inter-
net 3. From this 1000000 sites only 59026 have a direct IPv6 address, which represents a percentage
of 5.9%.
All the information present here shows us that the world is getting ready for IPv6, but how many people
use IPv6 nowadays? If we look at the data form Cisco 4, we can see that Switzerland has the highest
percentage of IPv6 users(8,9%) followed by Romania (7,69%) and France(5,07%). To have a real per-
ception of the percentage of IPv6 users worldwide let’s check the traffic that passes through Google 5.
The percentage of users that access Google over IPv6 more than double in just one year and it is now
above 2%. This traffic is generated without the use of tunnels, in fact the use of tunnels to connect IPv6
devices represents only 0.01% of Google traffic.
3.3 IPv6 in Portugal
There are 60 IPv6 allocations in Portugal 6, this number more than double in the last year. In the next
few years this number should increase, since Portugal’s trend is to continue to grow, as shown in Figure
3.3. In the last year this percentage decreased a bit but this happend because Portugal has a really low
number of ASes, so if a new AS appear and only has IPv4, this will have a big impact in any statistic.
Another important thing to retrieve from this figure is the position of Portugal, which is far ahead in the
percentage of ASes with at least one IPv6 prefix when compared to the world average. However if we
look to the Top 3 European countries, Portugal is still a bit behind. It has 13 ASes with at least one IPv6
prefix from a total of 64 ASes. The list of IPv6 allocations in Portugal until September 2013, can be seen
in table 3.5.
1http://k.root-servers.org/statistics/ROOT/monthly/ (last accessed October 1st, 2013)2http://bgp.he.net/ipv6-progress-report.cgi (last accessed October 1st, 2013)3http://www.alexa.com/topsites (last accessed October 1st, 2013)4http://6lab.cisco.com/stats/ (last accessed October 1st, 2013)5http://www.google.com/intl/en/ipv6/statistics.html#lab=per-country-ipv6-adoption(last accessed
October 1st, 2012)6http://www-public.it-sudparis.eu/~maigron/RIR_Stats/RIPE_Allocations/IPv6/ByNb/PT.html (last
accessed October 1st, 2013)
3.3. IPV6 IN PORTUGAL 19
Table 3.5: Companies with IPv6 prefixes in Portugal
20 CHAPTER 3. STATE OF THE ART
Figure 3.3: IPv6 allocations in Portugal
All this networks have /32 prefixes. The National Research and Education Network (NREN) from Portu-
gal (Fundação para a Computação Científica Nacional (FCCN)) for example uses its /32 to provide /48
prefixes to each university connected to its network. Other companies like Optimus, ZON or PT can use
their prefixes to provide IPv6 access to their clients when they request so. To do this they just have to
create subnets from their /32 prefix. These telecommunication companies already support native IPv6
in their backbone and are starting to offer IPv6 solutions to their enterprise costumers 1 2 3.
The percentage of IPv6 users in Portugal is just 0,71%4 but this number will keep increasing in the
next months/years just like in the rest of the world. Another relevant point to better understand the
development of IPv6 in Portugal is to look at the data provided by FCCN. According to the data from
January 2013, 12,6 % of daily consults in the primary ns.dns.pt were made using IPv6 already 5.
3.4 Transition Mechanisms
In order to have a successful transition, compatibility between IPv4 and IPv6 must be assure. For this
reason IETF has been working in specific mechanisms to allow a smooth transition between IPv4 and
IPv6. The transition should be transparent to the end-users, in other words a normal Internet user will
not have any idea that this transition is happening.
It is important to remember that the mechanisms used to assure the transition must be used for several
1http://www.zon.pt/institucional/PT/Media/Documents/3%206%202011%20ZON%20anuncia%20IPv6_PR.pdf (last accessed October 1st, 2013)
2http://www.optimus.pt/Main/SobreAOptimus/PressReleases/2011/6/6/3440151 (last accessed October1st, 2013)
3http://www.telecom.pt/ipv6/migrar-redes.html (last accessed October 1st, 2013)4http://6lab.cisco.com/stats/ (last accessed October 1st, 2013)5https://www.dns.pt/sondas-evolucao-anual-ipv6;jsessionid=545CF84010801D343115671902B52344.
jvm2 (last accessed October 1st, 2013)
3.4. TRANSITION MECHANISMS 21
years until IPv6 is fully deployed. There are three different types of transition mechanisms: dual stack,
tunnelling and translation.
3.4.1 Dual Stack
With this mechanism a network node maintains both protocol IPv4 and IPv6 stacks. This way any dual
stack node will use an IPv4 address obtained by DHCP to communicate with an IPv4 node and will use
an IPv6 address obtained by DHCPv6 or SLAAC to communicate with an IPv6 node. If dual stack is
implemented in a network, an application can choose which version of the IP Protocol to use depending
on the requirements of the application. This is the most direct way to perform the transition from IPv4 to
IPv6.
Since an IPv4/IPv6 host must be able to communicate directly with IPv4 and IPv6 nodes, DNS servers
must be capable of handling A records and AAAA records, because the DNS server that got the request
has no way to know the capabilities of the requesting node [19]. A node with a dual-stack implementation
can operate in three different manners: IPv4 stack enabled, IPv6 stack enabled and both stacks enabled.
With IPv4 stack enabled a node can only communicate using IPv4, with IPv6 stack enabled it can only
communicate using IPv6 and with both stacks enabled it can communicate using IPv4 or IPv6.
Dual stack assures higher throughputs and lower RTTs when compared to tunnelling mechanisms [9]
but unlike tunnelling, requires a big investment to buy new equipment or upgrade the existing ones. Not
only routers/switches and hosts must be upgraded, applications and services in the network like Simple
Mail Transfer Protocol (SMTP) or DNS must also support both versions of the IP protocol.
3.4.2 Tunnelling
Another technique is the use of tunnels. This is used to allow IPv6 nodes to communicate through an
IPv4 network. Routers and hosts that implement both IPv4 and IPv6 protocols can create point-to-point
tunnels to transmit IPv6 datagrams through an IPv4 network. To accomplish this, routers/hosts that will
send the datagram are able to encapsulate the IPv6 datagram in an IPv4 datagram. The encapsulation
consists in adding an IPv4 header to the IPv6 packet. The node at the end of the tunnel is responsible
for removing IPv4 header and forwarding the packet to its destination.
The most common type of tunnelling is router-to-router since the end points must be configured. These
routers must be dual stack and are the boundary between IPv6 islands and the IPv4 network. Tunnels
can be created manually at end-points or automatically. Automatic tunnelling includes 6to4, Toredo,
ISATAP, Tunnel Brokers and 6rd mechanisms.
22 CHAPTER 3. STATE OF THE ART
6to4 specifies an encapsulation mechanism to transmit IPv6 packets between IPv6 islands using a well-
known prefix over IPv4 network. 6to4 hosts use a common IPv6 prefix (2002::/16) followed by its IPv4
public address. To communicate with other 6to4 hosts, 6to4 routers are used at the networks edges.
6to4 hosts can also connect to native IPv6 host but in this case it is necessary the use of 6to4 relay
routers [20] as shown in Figure 3.4 1. Therefore 6to4 does not need to configure explicit tunnels.
6rd utilizes the same encapsulation and base mechanisms as 6to4 [21] and can be seen as an improve-
ment of 6to4 [20]. This mechanism does not advertise a common IPv6 prefix like 6to4, instead it uses
the IPv6 prefix of an Internet Service Provider (ISP), which eliminates some problems that are caused
by the use of a well-known IPv6 prefix. For example if a 6to4 relay router belonging to one ISP starts
advertising the prefix 2002::/16, this will provide open services not only for the ISP costumers but to
every other user aswell. To control access to their services an ISP can add rules in its relay router to
filter incoming packets. The problem emerges when a client from a different ISP near the 6to4 relay
router from the first ISP tries to send a packet. This packet will be forwarded to the 6to4 router and the
router will drop the packet, creating a black hole [20].
6rd also allows the use of private addresses (6to4 only works with public addresses), the only place
where an IPv4 public address is needed is at the border relay router.
ISATAP specifies a Non-Broadcast Multiple Access (NBMA) interface type to transmit IPv6 packets
over IPv4 networks. ISATAP is meant to be used within a site, enabling isolated IPv6 hosts within an
IPv4 network to communicate using tunnels. For this to work a link-local address is generated from
an IPv4 address. ISATAP interfaces configure IPv6 link-local addresses, which encapsulate an IPv4
address assigned to an underlying IPv4 interface within the IPv6 link-local prefix "fe80::/10" [22]. This
mechanism is designed to be used in networks where IPv4 is the dominant protocol. By implementing
1http://en.wikipedia.org/wiki/File:6to4.svg (last accessed October 1st, 2013)
Figure 3.4: 6to4 mechanism
3.4. TRANSITION MECHANISMS 23
ISATAP it is possible to achieve slightly better throughputs and lower RTTs than 6to4 [9].
Teredo suppresses one of the 6to4 problems. 6to4 requires that the tunnel end-points have a public
IPv4 address. Although ISATAP already solves this problem, it does not work across NATs. Well, with
the actual state of Internet this is a problem since NAT is present almost everywhere. Teredo solves
this problem by tunneling packets over UDP, with the help of Teredo servers and Teredo relays (both of
them must be dual stack). UDP was chosen because TCP and UDP are the only protocols guaranteed
to cross the majority of NAT devices [23] and if the choice was TCP, it would result in a poor quality of
service. Figure 3.5 shows the architecture of Teredo.
If a Teredo client located behind a NAT box wants to send a message to an IPv6 host he must follow the
following procedure [24]:
1. The Teredo Client sends an IPv6 ping to the remote interface through its Teredo server (encapsu-
lated in UDP and IPv4).
2. The Teredo server decapsulates and forwards the ping.
3. The ping reply goes to a Teredo relay.
4. The ping reply goes to the Teredo server.
5. The Teredo server tells the Teredo client what Teredo relay to use.
6. The Teredo client sends normal (encapsulated) traffic to the Teredo relay.
7. The Teredo client receives normal (encapsulated) traffic from the Teredo relay.
Figure 3.5: Teredo
Tunnel Brokers require the deployment of a tunnel broker server, which has to be dual stack [25].
The tunnel broker server is responsible for creating and managing the tunnel between the client and
24 CHAPTER 3. STATE OF THE ART
the tunnel server. Tunnel Brokers are a good way for individual hosts to connect to IPv6 sites. The
procedure followed by this mechanism is as follows:
1. The Client connects to the tunnel broker web interface and request a tunnel (after registering in
the broker system).
2. The broker sends the remote endpoint configuration to the tunnel server
3. Broker returns configuration to client system to create the tunnel
4. Tunnel is established
Dual-Stack Lite as the name states this mechanism uses the same approach as dual stack, but while
dual stack implementations force a node to have an IPv4 and an IPv6 public address, in ds-lite the IPv4
address may be private [26]. The Costumer-Premises Equipment (CPE) distributes private addresses to
the LAN clients, and then instead of performing NAT to communicate with the outside, CPE encapsulates
the IPv4 packet inside an IPv6 packet. This packet will be sent through IPv6 to the Carrier-Grade
NAT (CGN)(Figure 3.6 1). Then CGN uses its global IPv4 address to communicate with the IPv4
network. In order for this to work CGN must record the CPE public IPv6 address, the private IPv4
address and TCP/UDP port numbers.
Figure 3.6: DS-Lite mechanism
3.4.3 Translation
Dual stack mechanisms require a huge investment to update current equipment and invest in new ones.
On the other hand, tunnelling mechanisms connect IPv6 islands but are unable to allow the connection
between the IPv4 realm and IPv6 realm. So translation is needed to allow resource migration and coex-
istence between both protocols while the migration occurs. Also, services that are available through IPv4
1http://en.wikipedia.org/wiki/File:DSLite.svg (last accessed October 1st, 2013)
3.4. TRANSITION MECHANISMS 25
may not be available in IPv6. In these cases translation is the only solution. As the name states, transla-
tion enables direct communication between IPv4 and IPv6 hosts. Examples of translation mechanisms
are: DNS64, NAT64,Stateless IP/ICMP Translation (SIIT) and IVI.
NAT64/DNS64 These two mechanisms combined enable an IPv6-only client to initiate communication
with an IPv4-only server/client (Figure 3.7 1). DNS64 is a mechanism for synthesizing AAAA records
from A records when AAAA records are not found. The first part of the IPv6 addresses returned by the
DNS64 points to a NAT64 translator and the second part contains the IPv4 address of the A record. In
order to be able to perform IPv6-IPv4 translation, NAT64 requires a state that keeps information about
the binding of IPv6 addresses to IPv4 addresses [27].
These mechanisms are extremely useful for companies that are not yet prepared for IPv6. If a company’s
network does not have IPv6 support and wants their web servers to be available for IPv6 users, they
can use these mechanisms. This is not a definitive solution but can help companies to be present in the
IPv6 world while their infrastructures are not yet ready for IPv6. Many enterprises and service providers
already use this kind of solutions provided by A10 Networks and Infoblox 2.
Figure 3.7: DNS64/NAT64
SIIT is an effort to replace NAT-PT (also a translation mechanism), which was moved to historical status
by IETF, due to numerous problems [28]. This mechanism specifies a way to translate between IPv6
headers and IPv4 headers (and ICMP headers). It uses a specific IPv6 address pool to represent IPv4
systems.
IVI has three types of address translation: stateless 1:1 translation, stateless 1:N translation and stateful
translation. Stateless 1:1 translation is used when there is an IPv4 public address for each host. State-
less 1:N in the other hand is used when the IPv4 address pool is not enough for every host. In this case
several IPv6 addresses are translated into one IPv4 address. To make this possible IVI uses portcodind
[29]. Basically IPv6 addresses generated by the same IPv4 address will use different TCP or UDP ports.
1http://en.wikipedia.org/wiki/File:NAT64.svg (last accessed October 1st, 2013)2http://www.a10networks.com/resources/solutionsheets-Infoblox.php (last accessed October 1st, 2013)
26 CHAPTER 3. STATE OF THE ART
In stateful translation, addresses are translated dynamically, which has much more computational and
memory costs, on the other hand, in stateless transition address mapping is statically configured.
3.4.4 Evaluation of the Alternatives
Dual stack, tunneling and translation mechanisms give us different ways to ensure a smooth transition.
It is important to realize that these three mechanisms are complementary, and the three should be use
during the transition depending on each case.
At first sight, we would say that the perfect solution is to deploy dual stack in every piece of network
equipment on the world. However, this is not as easy as it may seem. The costs for massive deployment
of dual stack equipment would be too big for some companies to handle. In a time of recession like the
one we live in, companies are not willing to spend fortunes unless they are obligated to do so. This is just
one of the reasons why the penetration of IPv6 is so low. Money could be seen as the obvious reason
for not deploying dual stack everywhere, but there are others even more relevant. Protecting a network
against attacks/intrusions is not an easy task, since all the potential security problems in IPv4 will also
exist in IPv6 alongside with new vulnerabilities exclusive to IPv6. So if we add IPv6 to the networks,
network engineers would have much more work to assure that the network stays safe. However from my
point of view the problem with the implementation of dual stack worldwide is the lack of IPv4 addresses.
Companies which possess IPv4 public addresses or are located in areas where there are still IPv4
public addresses to be acquired can easily implement this solution, whereas companies with no IPv4
public addresses located for example in Asia are obligated to find other alternatives. These alternatives
are exactly tunneling and translation techniques. With the exhaustion of IPv4 address in Asia, IPv6
became the only solution. So, in order to allow companies and Internet users with IPv6 addresses to
communicate with the rest of the world, both tunneling and translation mechanisms are required or else
IPv6 users in Asia would only be able to communicate among themselves. This would result in an IPv6
island without the capacity to communicate with the IPv4 Internet or even with IPv6 islands on other
parts of the globe.
Companies which already have IPv4 public addresses allocated are clearly better positioned for IPv6
Table 3.6: Comparing the transition mechanisms
3.4. TRANSITION MECHANISMS 27
transition since they can profit from the advantages of the two worlds, IPv4 and IPv6. By implementing
dual-stack, companies are picking a solution that will enable them to communicate with both worlds in
the next 2 or 3 decades (until the last IPv4 station shuts down). At the end of this time they can turn off
IPv4 and communicate using only IPv6.
So why are companies with dual stack implementations better positioned? The reason is simple, trans-
lation and tunneling techniques have costs and these costs are the delay provoked in the network by the
tunneling of packets and the translation of IPv4 to IPv6 addresses. The consequences of using each
one of the transition mechanisms are expressed in Table 3.6.
28 CHAPTER 3. STATE OF THE ART
Figure 3.8: Transition Mechanisms
Chapter 4
Methodology for the Migration
Process
4.1 Introduction
Usually when we read something about IPv6 on the Internet or in a book we get the sensation that the
transition to IPv6 is an easy and simple procedure. People who believe in this idea have a very limited
notion of what is an IP network nowadays. Every single component in a network is connected to one or
multiple devices, each one with their own dependencies and limitations. Taking one device and enabling
IPv6 in it without consider its dependencies and devices connected to it, is not feasible. Nowadays most
of the network components require other services to work, for example: enabling IPv6 in our web server
is useless if DNS is not prepared to handle AAAA records (IPv6 records). Still, making DNS able to
resolve these records is not enough if the network itself cannot handle IPv6: routing equipment must be
able to handle IPv6 traffics, desktops need to have IPv6 enabled, DHCPv6 must be configured to give
IPv6 addresses to desktops (SLAAC and static configuration can also be used) and so on. Thus, the
network must be seen as a whole and not as the sum of all components. If this point is not respected,
we probably will end with connectivity issues and security breaches in the network.
There is not a simple and straight way to perform the migration from IPv4 to IPv6. As we have seen, the
dependencies between components in the network will determine and hamper the migration path that
must be followed.
29
30 CHAPTER 4. METHODOLOGY FOR THE MIGRATION PROCESS
4.2 Generic Migration Process
The purpose of this section is to create a migration process, which can serve as a reference/guideline for
a team of engineers responsible for migrating their company’s network to IPv6. However each network
has its own specifications, therefore a specific migration plan must be created for each case. In some
cases this plan will be identical to the one proposed here, but in others cases may be necessary some
modifications depending on the type of network and its requirements. We can look at these steps and
view them as a generic set of steps for a transition towards IPv6. The plan proposed aims to ensure 5
objectives:
An IPv6 enabled network - obviously this is the main objective of the migration plan
Minimize costs - One of the main reasons for the low penetration of IPv6 worldwide is the costs asso-
ciated with its transition. As we all know, the world’s economy already had better days, so do not expect
that the majority of companies will spend thousands or millions of euros in this subject until it is strictly
necessary. Therefore it is essential to design a plan taking this into account.
Minimize the risk associated with the migration to IPv6 - There are risks when performing something
as complex as a transition from IPv4 to IPv6. In a task like this one it is extremely easy to miss something
and leave the network vulnerable. The team of engineers responsible for this task must pay special
attention to security and connection problems that may arise. It is fundamental to create a testbed
before the actual implementation, to assure that all services in the network and the network itself can
run with no failures, or else a company may do a huge investment in IPv6 only to find out that some
services do not work and some places of the network are not reachable.
Ensure the smoothness of the process - The process should occur in a smooth and manageable
manner. It is important that the migration plan is well structured and covers all aspects of the transition.
Go unnoticed - If possible the transaction towards IPv6 should be transparent to network users. Efforts
should be made to minimize possible disruptions on the network.
The migration process presented below was based on the RFC 4057 [30] and 4852 [31], who already
define some points to be taken into account when performing a migration to IPv6. It has 9 phases:
1. Analysis of the current situation
(a) Enterprise business
(b) Technological maturity of company
(c) Critical applications for the business
2. Present a study focused on the migration impact for the company
4.2. GENERIC MIGRATION PROCESS 31
3. Survey of the enterprise’s network
(a) Network
(b) Equipment
(c) Applications
(d) Services
4. Analyse IPv6 support from ISPs
5. Estimate the costs of migrating the company’s network
6. Migration plan
(a) Upgrading or replacing equipment without IPv6 support
(b) Addressing plan
(c) Phased deployment of IPv6 into the network
(d) Treat network’s dependencies without IPv6
(e) Partial decommissioning of IPv4
(f) Decommissioning of IPv4
7. Testbed
8. Identify problems
9. Final implementation
In the remainder of this chapter we will present each phase in greater detail.
4.2.1 Anaysis of the Current Situation
The business of the company must be analysed, to better understand the consequences that IPv6 can
have on the enterprise. It is easy to realize that some businesses rely on networks more than others.
To propose a migration from IPv4 to IPv6 in a small company with a very limited network is an entirely
different thing than creating a migration plan for a big company. If we are creating a migration plan for
a company with multiple branches, we must take into account the interconnections between all of these
branches. It is probably not a good idea to create a migration plan for just one part/branch of a company,
because there will probably exist dependencies from other points of the company’s network. This could
result in a company being able to migrate its central office to IPv6 and communicate with the outside
but being unable to communicate with other points of its own network, because these points were not
32 CHAPTER 4. METHODOLOGY FOR THE MIGRATION PROCESS
considered in the migration plan. For the same reason, clients that want to access services located
outside of the central office will not be successful. Therefore a migration plan should only be established
if a "full picture" of the company’s network is available. If, for some reason it is not possible to fulfill this
requirement, the migration plan should be delayed.
The list of requirements will be different for every company, not only based on their size and business
but also in their technological maturity. Other major concern should be the applications and services
that the company uses and it depends on. If a critical service or application for the company does not
support IPv6, a solution must be found.
4.2.2 Present a Study Focused on the Migration Impact for the Company
Some companies already are fully aware of the need to migrate to IPv6, making this step a courtesy or
even unnecessary. However a large percentage of companies worldwide do not know why they have
to migrate to IPv6 or the advantages that this new version of the Internet Protocol can bring. For those
companies this is an early but crucial point. If the managers of the company are not convinced that they
will gain something by migrating to IPv6, they will not spend money in this project, at least for now. So
one must present a study that shows the benefits that an early IPv6 adoption can bring to the company.
4.2.3 Survey of the Enterprise’s Network
An exhaustive analysis of the enterprise network is needed to better understand what has to be done
in order to proceed with the migration. This is one of the most important aspects in a migration plan
because in order to obtain a fully functional IPv6 network, the topology of the network must be fully
analysed to guarantee that the right decisions are taken. It is not possible to create a good migration
plan for an enterprise if we do not have full knowledge of their network. One must have knowledge
of every component of the network and its dependencies to establish a secure and reliable transition.
Network topology is just one of the things to be taking into account when we are analyzing a network.
Every component in the network should be analysed, like:
• Routers and switches
• Services
• Applications
• Firewalls
• Routing protocols
4.2. GENERIC MIGRATION PROCESS 33
• Printers and other devices
4.2.4 Analyse IPv6 Capacity from ISPs
Not all ISPs are prepared for IPv6. Some of them did not even start to plan their transition to IPv6 [32],
so the ISP or ISPs of the company must be contacted in order to understand which type of services are
they offering through IPv6. After that, one can analyse the different offers and decide which ISP(s) has
the better offer and is more reliable. It is important to ear the ISP’s plans for IPv6 because a migration
plan done now can be put in practice only in a few years. By then an ISP that is not offering IPv6
connectivity right now, can have their services fully operational through IPv6.
4.2.5 Estimate the Costs of Migrating the Company’s Network
After the analysis to the company’s network and to ISPs responsible for providing Internet and other
services to the company, it is a good idea to estimate the costs of this operation, using the information
obtained in the preceding steps. The equipment and services that must be upgraded or replaced must
be specified. Alternative solutions should be presented for replacing these services and equipment with
no support for IPv6.
In this phase one must know what type of approach the company wants to follow. There are four different
paths for the company to follow:
• Upgrade entire network to IPv6 - This will result in a mass implementation of dual stack equip-
ment, providing the network with the capability to communicate regardless of the protocol used.
While this is the best solution, since all the others are just temporary, it is also the most expensive.
It will be necessary to configure, upgrade or replaced every single network equipment and service
in the network.
• Upgrade some parts of the network to IPv6 - by upgrading only parts of the network it will be
necessary to have dual stack equipment on the edges dividing IPv6 from IPv4 networks, tunneling
mechanisms to tunnels IPv6 packets through the IPv4 network and translation mechanisms if the
company desires to have communications between IPv6 and IPv4 users and services.
• Create a new network - If a company wants to create a new network, it has to decide between
a dominant IPv6 network and an IPv4 dominant network. The best approach would be creating
a full dual stack network, allowing communications using both version of the Internet Protocol.
Some restrictions exist here, it is necessary to understand if there are still IPv4 public addresses
available, if not, an IPv6 network is the only solution.
34 CHAPTER 4. METHODOLOGY FOR THE MIGRATION PROCESS
• Keep an IPv4 network able to communicate with IPv6 users - A company may prefer to keep
their network as it is and simply add translation mechanisms to allow the access to some of their
services like the web portal.
With all this in mind and taking into account the choices of the company it is possible to do a feasible
estimation of the costs involved in this operation.
4.2.6 Migration Plan
With the information obtained in the preceding phases, a migration plan can start to be defined. In order
to proceed with the migration plan it is essential that the costs for migrating to IPv6 have already been
estimated. If the document with the costs estimation is not elaborated, it is necessary to perform, in this
step, the analysis of the network equipment and to choose which type of migration the company wants:
upgrade the entire network to IPv6, upgrade some parts of the network to IPv6, create a new network
or keep an IPv4 network that is able to communicate with IPv6 users.
As soon as the migration plan gets an approval by the company’s administration it is time to start the
actual migration. This plan should include all the proceedings that must be followed in order to achieve
a successful migration, starting with the training of IT staff and ending with the IPv4 shutdown.
Before starting the transition to IPv6, there are some things that must be done first:
• Every department in the company is informed about the IPv6 migration.
• Give IPv6 training to the IT staff (or else they are not able to migrate the infrastructure and maintain
it).
• All software developed inside the company takes IPv6 into consideration
• All software and hardware acquired from that moment on must support IPv6. If the equipment
needed does not have IPv6 support and no feasible alternatives are available, the equipment’s
suppliers should be questioned about their road map for IPv6. If there is none, the equipment can
be acquired but the company will have to use mechanisms like NAT64 to allow its use in an IPv6
only network.
• Acquire an IPv6 address block from its LIR.
• Define a lab environment to make some experiences with IPv6. This way, there is no risk to disrupt
the services.
• Learn with others mistakes. If possible analyze similar IPv6 migrations in other companies to avoid
mistakes and problems that may have occurred.
4.2. GENERIC MIGRATION PROCESS 35
With all that done, we can proceed to the implementation of IPv6 in the network. However this process
should be done carefully and divided into different stages:
1. Upgrading or replacing equipment without IPv6 support
All the information needed for this task is present in the document elaborated about the estimation
of costs.
2. Addressing Plan
Since the address format in IPv6 is different from IPv4, a company has to make an all-new ad-
dressing plan. This procedure must be done carefully, so that the available pool of IP addresses is
not wasted and it is distributed accordingly to the different departments in the company. There are
rules that should be followed when designing an addressing plan, just like in IPv4. Due to the size
of the IPv6 addresses, it is very important to follow these rules because with such a large space of
addresses to use, the probability of the address plan becoming a mess is too high. Before doing
the address plan the company should acquire an address space from its ISP or its RIR (if we are
talking about an ISP). However if for some reason the company still does not have an address
block attributed, it is possibly to design an addressing plan without having an address space at-
tributed. If this happens, the plan just has to be adapted to the range of addresses acquired by the
company.
3. Phased deployment of IPv6 into the network
After having an addressing plan we can start to migrate the company’s infrastructure to IPv6. To
achieve a successful migration we should enable IPv6 in the following order:
• Routers, firewalls and switches
• Basic network services
• Workstations
• Servers
If the company has a Demilitarized Zone (DMZ) to protect the internal network from unwanted
accesses, we should enable IPv6 in the internal network and only after should we proceed to
enabling IPv6 in the DMZ. Therefore we can mitigate network problems created with the use of
IPv6 in the network and correct them before proceeding with the migration in the DMZ. When we
refer to network problems, we are mostly speaking about security problems arising from enabling
IPv6. Security is a major concern because it is not feasible to migrate to IPv6 if that means less
security in the network. For this reason we should pay special attention to the security rules and
policies in the network and guarantee that the transition to IPv6 will not compromise the network.
36 CHAPTER 4. METHODOLOGY FOR THE MIGRATION PROCESS
It is important to realize that IPv6 brings new security problems that need to be handled. Besides
that a transition to IPv6 means in most cases that the network will operate in dual stack, therefore
the security problems will double: the ones from IPv4 will still exist and the same ones will be
created for IPv6. Thus new security rules and policies must be created to ensure the network’s
safety. These rules are not just to replicate the existing rules to IPv6, we must pay special attention
to possible failures in the network caused by the IPv6 protocol.
Other aspects that we need to take into account are for example the routing protocols to use with
IPv6. It is necessary to understand if the routing protocols in use have a correspondent version for
IPv6 and if they are still the best option, because the versions for IPv6 can have slightly differences
(in performance for example) which justify the change in the network protocol. Configuration of
hosts should require an analysis for understanding which type of configuration should be used.
For routers and servers, manual configuration is clearly the best option but what about hosts?
Should we use DHCP as in IPv4 or use SLAAC and take advantage of "plug and play networks"?
It is even possible to use a mix of both; therefore these questions should be analysed and then
answered.
4. Treat network’s dependencies without IPv6
There may exist some services that cannot be upgraded or even replaced to support IPv6. In
these cases, we must find plausible alternatives. If there is no viable alternative we may try to use
a solution like NAT64/DNS64 allowing these services to communicate with IPv6 devices.
5. Partial decommissioning of IPv4
When the use of IPv4 has reduced drastically and is no longer relevant we should decommissioning
IPv4 from workstations and servers and use DNS64 and NAT64 to allow existing IPv4 users to
communicate with the rest of the network.
6. Decommissioning of IPv4 With the end of IPv4 traffic we are finally able to turn off IPv4. All the
monitoring and management over IPv4 can be decommissioning. Translation services like DNS
64 and NAT64 can also be decommissioning. IPv4 addresses are returned to the respective LIR.
4.2.7 Testbed
The IT department should create a platform to test a scenario as close to the real one as possible. This
step is essential because a migration plan is much more reliable if it is based on a carefully defined
testbed. The testbed and the migration plan may be elaborated together, this way it is possible to realize
almost immediately if the recommendations written are viable or should be replaced.
4.2. GENERIC MIGRATION PROCESS 37
4.2.8 Identify Problems
In the Testbed all possible situations should be tested in order to discover potential limitations. All the
problems encountered like connectivity issues must be registered in this phase, so that problems like
these are eliminated when the implementation starts.
4.2.9 Final Implementation
With a migration plan defined and tested we can finally perform the migration to IPv6 according to the
migration plan created.
Chapter 5
Practical Case
5.1 Introduction
In this chapter we will use the migration process we just defined(with some modifications) to migrate a
subset of the data centers’ network of Refer Telecom to IPv6. We will use just a subset of the network
because i had to sign a Non-Disclosure Agreement and Refer Telecom choose to keep confidential many
of the information regarding its network. However this is not the only reason, the size and dimension of
this network makes it impossible to produce a migration process in such a small period of time.
From the migration process defined there is one point that will be suppressed. We will not analyze
the IPv6 support from Refer Telecom’s ISPs. First of all, Refer Telecom is already an ISP and second
we cannot analyze the ISPs to which Refer Telecom has direct connections, because that information
was not provided since it is out of the Refer Telecom’s interests for this work. The phase 3 of the
migration process (Survey of the enterprise’s network) will focus only on the network infrastructure of
Refer Telecom and its data centers, so we will call it "survey of the network infrastructure". The detailed
analysis to equipment, services and applications will be performed in phase 5 (Estimate the costs to
migrate the company’s network).
5.2 Analysis of the Current Situation
Refer Telecom was founded in 2000 and has Refer as sole shareholder. One of the main objectives of
the company is the management and exploitation of the telecommunication infrastructure integrant of
the national railway network. It is licensed by Autoridade Nacional de Comunicações (ANACOM) as a:
fixed telephone service provider, public network operator within Portugal, registered data transmission
39
40 CHAPTER 5. PRACTICAL CASE
and Internet Service Provider, VoIP Service Provider and Global System for Mobile Communications -
Railway (GSM-R) Service Provider.
Refer Telecom is a railway telecommunications operator and a regular telecommunications operator
which provides specialized telecommunications and IT service. With this information we can divide the
business areas in two components: management of railway telecommunications and the supply of IT
services to the business sector.
The company counts on 167 employees and it has a business volume valued in 23,1 million euros(2012
data). From this value, 51.5% (11.9 million euros) are associated to the railway component, whereas
the remaining 48.5% (11,2 million euros) come from the competitive market. Regarding the investment
made, Refer Telecom invested in the last year approximately 5,5 million euros. This investment level
should be maintained or increased in the next years in order to proceed with the IPv6 transition in its
data centers. According to the financial report from 2012 the Refer Telecom strategy is focused on:
"to ensure an effective management of the telecommunication infrastructures concession by the share-
holder, guaranteeing excellent services, as well as the optimization of all resources, through specialized
offers to the remaining markets". Concerning the services provided, as explained before, they are di-
vided in two components. In the railway telecommunication area, Refer Telecom provides the following
services:
• Operational telephony service - fixed over VoiP and mobile over Trunk and GSM-R
• Data transmission services - wireline network over IP/Multi Protocol Label Switching (MPLS),
Synchronous Digital Hierarchy (SDH)/Plesiochronous Digital Hierarchy (PDH) and wireless net-
work using GSM-R/General Packet Radio Service (GPRS), Global System for Mobile Communi-
cations (GSM)/Universal Mobile Telecommunication System (UMTS), WiFi
• Supervision and monitoring of infrastructures
• Traction remote control
• Video surveillance
• Videoconferencing
• Passenger information and public address system
• Time Synchronization
• Railway telematics solutions
• Consultancy
5.3. PRESENT A STUDY FOCUSED ON THE MIGRATION IMPACT FOR THE COMPANY 41
The TI and communications area is directed to the business sector and emerged from the necessity to
monetize the existing network infrastructure. Its most relevant services are:
• Dark fiber rental
• Fiber optical networks and international connection
• Internet access and virtual private networks
• Leased lines and Ethernet connections
• Storage
• Disaster Recovery
• Voice
• Faxmail
• Background Hosting
• Online help desk
• Creation, management and monitoring of virtual environments
Most of the services presented above rely on the network protocol in use. If we remove this protocol
the chances that something (or everything) will fail is huge. This is because even if the network and its
services support an alternative protocol (IPv6), it is not configured. With the emergence of IPv6, it is
necessary to ensure that all the services listed above will still work if we decide to use IPv6 instead of
IPv4 as the network protocol. However, since IPv4 will stay with us for many years our objective should
be assuring the proper functioning of the network and all of its services regardless of the protocol in use.
5.3 Present a Study Focused on the Migration Impact for the Com-
pany
While IPv4 is coming to its end, it is necessary that telecommunication operators, companies and gov-
ernments are ready to respond to the challenges brought by IPv6.
The telecommunications industry is the Internet’s backbone, and so it has an intermediary role between
all information that flows across the Internet. By being a telecommunication operator, Refer Telecom
42 CHAPTER 5. PRACTICAL CASE
should be able to answer their clients’ necessities as well as creating new partnerships and businesses,
taking advantage of its unique position.
By being proactive instead of reactive in the transition to IPv6, the company will have more time to
find the most suitable migration plan for it. The elaboration of a timely migration plan will avoid bad
investments in equipment. For example without a migration plan and no concerns regarding IPv6, a
company that needs to buy equipment will not take IPv6 into consideration when is making a purchase.
So in a couple of years, the company will have to replace a perfectly good and new machine just because
they did not check its IPv6 compatibility.
With the end of IPv4 addresses there are already users that can only access the Internet over IPv6. This
just happens in Asia for now, but in a couple of years the same thing may happen in Europe. There is
here a niche market waiting to be explored by pioneering companies. To corroborate this affirmation let’s
look at Google data about IPv6: about 2% of Google users already use IPv6 to reach Google servers.
This percentage will keep growing until the point where IPv4 traffic will just disappear. Just in the last 10
months the IPv6 traffic doubled, so we can expect that in a few years we will have here a huge market
to be explored. Taking this into consideration, it is obvious that companies ready for IPv6 are one step
ahead of the remaining. They can provide its contents and services to all clients and potential clients
over IPv4 and IPv6.
Refer Telecom already gave the first step into the IPv6 World when they enabled IPv6 in their Wide Area
Network (WAN). The technique used to do so, was dual stack. Therefore the entire WAN network is able
to work with both versions of the Internet Protocol. However, this effort must now be propagated to the
remaining network, specifically the data centers. By enabling IPv6 in the data centers, Refer Telecom
makes sure that all the services and content offered by them, are available to all clients over IPv4 and
IPv6.
As it is known, Refer Telecom intends to build a new data center in Lisbon, due to the limitations of the
existing one. So it is fundamental that all equipment acquired to the new data center has IPv6 support.
Not only the IPv6 support should be taken into account, the performance of equipment using IPv6 is
very important as well. Regarding the performance, we may look for certifications possessed by the
equipment to see if it has the necessary requirements.
5.4 Survey of the Network Infrastructure
The network of Refer Telecom is structured according to figure 5.9. The access to the data centers
is made through IPv4 regardless of the type of access. All accesses for monitoring and management
from the Direction of Information and Technology (DTI), as well as accesses from internal and external
5.4. SURVEY OF THE NETWORK INFRASTRUCTURE 43
clients can only be made through the WAN network (data network). All data centers possess redundant
connections between them, so that Refer Telecom can fulfill all its SLAs in cases of malfunction or loss of
connection. All data centers are also connected over fiber channel for storage purposes (not presented
in the figure). The WAN network of Refer Telecom already has IPv6 enabled, so if we want employees
of the different departments of Refer Telecom (internal clients) and its clients (external clients) to have
access to the services in the data centers over IPv6 we need to migrate all the equipment in these data
centers to IPv6. Since all the network between the internal clients and the data centers is IPv6 enabled
there is nothing else to do besides migrating all the equipment and services available in the data centers.
For the internal clients they just need to have IPv6 enabled computers. Regarding external clients, it will
depend on the type of solution acquired by them. If they have solutions that already take IPv6 into
account, perfect, otherwise they will need to discuss with Refer Telecom what type of changes need to
be made to the connection. These changes might be more or less complex depending on the type of
network.
With the migration of the data centers to IPv6 it will be possible for the Direction of Information Technol-
ogy to perform the maintenance, monitoring and management of the data centers over IPv4 and IPv6
since they are part of the internal clients of Refer Telecom.
Taking into account the associated costs and the fact that we are talking about an ISP, the best approach
is based on dual-stack. Other type of approaches like tunneling and translation are not definitive solu-
tions and create unnecessary delays due to the modifications that need to be made in the IP packets.
Therefore we can guarantee that any user in the network can reach the services in the data centers
using both versions of the IP protocol. However, in some cases we may have services or equipment that
cannot be upgraded to IPv6 or replaced. In these cases we should consider other type of solutions like
the ones mention above.
Figure 5.10 shows the internal structure of one of the three data centers of Refer Telecom. The services
that can be accessed from the Internet, like DNS or the website, are located in the DMZ. This way, they
are separated from the internal network, avoiding that a possible attack to a server in the DMZ can be
propagated to the internal network.
In the next section we will present a survey of the existing services, applications, routing and firewalls
equipment regarding their IPv6 support. The reason of this survey is to find and identify which devices
must be upgraded or replaced in order to enable IPv6 in the data centers.
44 CHAPTER 5. PRACTICAL CASE
Figure 5.9: Refer Telecom network
Figure 5.10: Data centers network
5.5. ESTIMATE THE COSTS OF MIGRATING THE COMPANY’S NETWORK 45
5.5 Estimate the Costs of Migrating the Company’s Network
The transition from IPv4 to IPv6 is not as simple as it may seem because all network components are
interconnected. We cannot replace a device without the risk of compromising all the ones connected to
it. For example if we replace a DNS server and the changes are not correctly advertised into the network,
the whole network will collapse. Therefore all equipment and services dependencies must be known, in
order to ensure a successful transition. This transition affects many subjects: hardware, IP addressing,
routing protocols, security, DNS, DHCP, VPN, monitoring and any other services or applications provided
by the network. Table 5.7 shows the subjects that need to be taken into consideration and what need
to be modified in order to achieve an IPv6 enabled network.
To understand what has to be changed we made a survey regarding the services and applications
present in the Refer Telecom data centers. We should identify which ones already have IPv6 support
and which ones must be upgraded or replaced.
5.5.1 Backup and Storage
HP Data Protector is a software from HP for backups. This software is composed by three components
who utilize the IP protocol to communicate (as shown in figure 5.11): the Cell Manager (CM), the Media
Agent (MA) and the Client. The CM is the brain of the system; it contains the list of clients and manages
the beginning and ending of backups. It is also responsible for installing a Data Protector agent on the
client where we want to perform the backup. The MA is responsible for asking the data from the client
and injecting it in the SpectraT950 (Tape library used by Refer Telecom) or in the EMC Data Domain
(Virtual Tape Library used by Refer Telecom). The CM and the MA can coexist in the same machine but
in Refer Telecom they are located in different machines due to resource distribution policies.
All communication between these 3 components is made using IPv4. Thus, if we want to use IPv6
instead of IPv4 we need the three components to support IPv6. Data protector is IPv6 aware since
its version 6.2. Nowadays Data protector is already on version 8. While the communication between
these components is all made over IP, the communication between the MA, the Spectra T950 and the
EMC Data Domain is not. These devices trade information over Fiber Channel, therefore this part of the
network as no influence in the migration process. However the management of these devices is made
over IPv4, so we need to check their IPv6 support. The SpectraT950 has limited support for IPv6, since
it is possible to perform the management through a browser over IPv6, but only in the local network.
Refer Telecom has two major solutions for backups. One we already analyze and the other is the EMC
Avamar. Opposed to HP Data Protector, the EMC Avamar is 100% based on IP. It is composed by one
node called Avamar Utility Node, storage nodes and by the client. The Utility Node has a function pretty
46 CHAPTER 5. PRACTICAL CASE
Table 5.7: Affected componenets
Figure 5.11: Data Protector
5.5. ESTIMATE THE COSTS OF MIGRATING THE COMPANY’S NETWORK 47
similar to the one performed by the CM in Data Protector. It is responsible for connecting to the client in
order to initiate the backup to the storage nodes. Both the solutions referred here perform deduplication,
which means that they are able to identify identical blocks and only save them one time. However,
Avamar is able to reduce the network load since it only sends the blocks that have been altered whereas
Data Protector sends all blocks and only at the destination performs its analysis. Thus, EMC Avamar
has a huge advantage, since it can reduce the network load up to 99%. Unfortunately EMC Avamar has
a big problem for us: it has no IPv6 support. Therefore it is not possible to do backups through IPv6 with
this software. However if we need to back up an IPv6 only system using Avamar, we can use NAT64
and DNS64 to make this possible. With these techniques the IPv6 system will appear as a regular IPv4
system to the EMC Avamar.
Regarding SAN Storage, the predominant protocol is fiber channel. So, the IP protocol is only used for
management. Refer Telecom uses the EMC Control Center for this propose. It is also used by Refer
Telecom the HP 3par Inform Management Console and the EMC Symmetrics Management Console.
This software is used to manage the HP 3par and the EMC Symmetrics respectively. For last Refer
Telecom uses the IBM V7000, this software also uses the IP protocol for management.
The EMC Control Center has IPv6 support since version 6.1. Regarding EMC Symmetrics, the version
Symmetrics V-Max Engenuity 5874 obtained the IPv6 Ready Logo Phase 2 in the Core Protocols cate-
gory. The IPv6 Ready Logo "is a conformance and interoperability testing program intended to increase
user confidence by demonstrating that IPv6 is available now and is ready to be used."1. Equipment
with this Logo has performed a battery of tests and received a positive feedback. There are different
categories: IPv6 Core Protocols, IPsec, DHCPv6, Management and MIPv6. There are other categories
but they are still in an experimental phase, so no logos are granted to them.
The IBM solution also has IPv6 support since version 6.1, which allow us to connect to the graphical
management interface through IPv6. On the other hand the HP solution does not have IPv6 support,
hence, the management of that device must still be performed over IPv4. If we need to have IPv6 access
to this device we can use also a solution with NAT64/DNS64.
For last Refer Telecom uses the EMC Celerra VG2 as NAS (Network-Attached Storage). It is used to
create a centralized file server service for the whole network. This platform has IPv6 support, hence, all
request made from users to the server can be done over IPv4 or IPv6.
5.5.2 Virtualization and Monitoring
Nowadays virtualization is one of the most important components of a company, especially an IT related
company. Refer Telecom uses as a virtualization tool the VMware Vsphere, which consists of a bundle1https://www.ipv6ready.org/ (last accessed October 1st, 2013)
48 CHAPTER 5. PRACTICAL CASE
of virtualization software. Refer Telecom has some of this software, including ESXi, Virtual Center and
Vcloud Director. ESXi is the hypervisor and it creates and runs virtual machines in a shared storage.
Virtual Center is a centralized application to perform management of the ESXi over the network. For
last but not least the Vcloud Director is used to create virtual environments and it allows us to allocate
storage, CPU and memory to the clients. With this tool, the clients themselves can build their own virtual
data centers.
Naturally all these components utilize the IP protocol to communicate. Both the ESXi and the virtual
Center have IPv6 support, the first one since version 3.5 and the second since version 4.1. On the
other hand, Vcloud Director does not have IPv6 support. Since this software interacts with ESXi, Virtual
Center and storage, it is not possible to use it with IPv6. However, it is likely that VMware, introduce IPv6
support for Vcloud Director in future releases.
The ESXis are installed in blades belonging to the HP BladeSystem. The management of this equip-
ment is performed over the network through the HP BladeSystem Onboard Administrator, which already
supports IPv6.
Refer Telecom also uses the HP Systems Insight Manager to monitor all its HP equipment. This tool is
not properly prepared for IPv6 yet, because it can only show the IPv6 addresses of the machines (if they
are configured) and it uses IPv4 to get that information.
5.5.3 DNS
The DNS service is essential for any IP network, since it is responsible for resolving a domain name (ex:
www.referelecom.pt) into the corresponding IP address.
Refer Telecom data centers have 2 distinct DNS servers, one for the internal clients and another for the
external ones. The internal DNS server is located in the internal network of the data centers whereas
the external one is placed in the DMZ. The external DNS server is BIND from ISC while the internal one
is the DNS server from Microsoft. The internal DNS supports IPv6 (Microsoft DNS server supports IPv6
since version 2008) and it is resolving IPv6 requests, but we need to find if the requests to the DNS
server are being made through IPv6 or if they are still using IPv4. Although BIND supports IPv6, the
external DNS is not resolving IPv6 requests yet. BIND supports IPv6 since version 9, however we should
always use the most recent version (the last stable version is 10.1) because there are some versions
with some security problems that can be exploited like version 9.1 for example.
5.5. ESTIMATE THE COSTS OF MIGRATING THE COMPANY’S NETWORK 49
5.5.4 Windows
Microsoft solutions are widely used by Refer Telecom, starting from Windows operating systems for
both PCs and servers until Exchange,DNS, DHCP, SQL Server, Lync, TMG or Sharepoint. With all
these services in use, it is easy to realize that Refer Telecom uses Active Directory to integrate them.
Thus, it can centralize all authentications and permissions to everyone of those services in a single
software.
Now that we already identified all the Microsoft products used by Refer Telecom let’s check their IPv6
support:
• Active Directory works with IPv6 if the version of Microsoft Server where the AD is running is equal
or higher to 2008
• Exchange Server supports IPv6 since version 2007 with Service Pack1, however it needs to be
installed on Windows Server 2008 and have both IPv4 and IPv6 activated. Refer Telecom uses
the version 2010. This version has IPv6 support, but we also need to have IPv4 activated in order
to use IPv6. Since Refer Telecom pretends to have dual stack in its network, there is no problem
here.
• DHCPv6 was introduced by Microsoft on Windows Server 2008
• Lync supports IPv6 in its newer version: Lync 2013. Refer Telecom has the 2010 version, so it
needs to upgrade Lync and install it on Windows Server 2008 with the lastest service pack at least.
• SQL Server supports IPv6 since version 2005 but needs to be installed on Windows Server 2008
or higher. If SQL Server 2005 is used and it is installed on Windows server 2008 we need to install
Service Pack 2 if we want to use IPv6 only. Refer Telecom will have no problem with SQL Server,
since all versions used for SQL Server and Windows Server are within the established standards.
• SharePoint supports IPv6 since version 2007 and it can be installed in any version of Windows
Server since 2003. However for Windows Server 2003, IPv4 must be activated and we have to
install IPv6. Refer Telecom uses SharePoint 2007 on top of Windows Server 2003 and SharePoint
2013 on top of Windows Server 2012(Standard).
• The Microsoft operating system for PCs supports IPv6 since Windows XP with Service Pack 3.
Windows Vista, Windows 7 and Windows 8 possess the IPv6 Ready Logo Phase 2 on Core Pro-
tocols category. Windows Server 2008 and 2012 also have this logo.
50 CHAPTER 5. PRACTICAL CASE
5.5.5 Linux
- The operating systems based on Linux are also used by Refer Telecom, both in PCs and servers. The
following list shows the operating systems used and their IPv6 support:
• Ubuntu - The first version of Ubuntu with full IPv6 support is 11.04, however this version has some
problems with the network manager and its configuration for IPv6. These problems were correct
in version 11.10.
• Debian - The operating system Debian fully supports IPv6 since version 6 (Squeeze)
• SUSE - SUSE is IPv6 enabled since version 11 and with SP1 got the IPv6 Ready Logo Phase 2
on Core Protocols category.
• Red Hat Enterprise Linux - Red Hat also has the IPv6 Ready Logo Phase 2 on version 5 and
6. Version 5 has that logo in the categories of Core Protocols and IPsec and version 6 has be-
yond those 2, the categories of DHCPv6 and SNMP. Older versions already support IPv6(IPv6
functionalities were introduce since version 3), however we should use the newer versions.
• CentOS - CentOS is based on Red Hat Enterprise Linux, so they both follow the same matrix
regarding IPv6. The numbering of CentOS version is made according to Red Hat versions, hence
the version 3 of CentOS corresponds to version 3 of Red Hat, version 4 of CentOS corresponds to
version 4 of Red Hat and so on.
5.5.6 Routers
As shown in figure 5.9, the access to the data centers is made through two routers. The main connection
is made through a Cisco Catalyst 6500 whereas the redundant connection is made through a Cisco
Catalyst 4500.
In order to support IPv6 in the Cisco Catalyst 6500 prior to the release 12.2(33)SXI, we needed to
buy an additional license from Cisco. From this version on, the IPv6 support is already included in the
default firmware. This equipment has the IPv6 Ready Logo Phase 2 on the Core Protocols category
since release 12.2(33)SXI. The Catalyst 4500 is in a similar situation. Before the release 12.2(54)SG,
it also needs an additional paid license to support IPv6. This equipment also has the IPv6 Ready Logo
Phase 2 in the same category since version 12.2(52)SG. Catalyst 6500 and 4500 also have the USGv6
(US Government version 6) certification since versions 12.2(33)SXI3 and 12.2(54)SG respectively. A
entity like the US Government cannot afford to use equipment with security vulnerabilities that can be
exploited, so they created this certification to ensure that equipment with this certification, have no
vulnerabilities and can be used safely.
5.5. ESTIMATE THE COSTS OF MIGRATING THE COMPANY’S NETWORK 51
IPv6 support is not the only thing that matters when we look at a router. We should take their perfor-
mance into account as well. Cisco routers have similar throughput and latency for IPv4 and IPv6. These
values only suffer a minor decrease in throughput and a slightly increase in latency when we use IPv6
for small packets (less than 256 bytes). This happens due to the difference in the size of the IP headers.
5.5.7 Firewalls
Firewalls are a fundamental aspect in any network. They are responsible for maintaining the network
secure from external threats. It is important to realize that no one will introduce IPv6 in a network if that
means less security for the network. Firewalls have to guarantee at least the same level of security for
IPv6 when compared to IPv4. To do that, all existing policies for IPv4 need to be replicated for IPv6 and
we also need to add policies to protect the network against IPv6 only threats.
To control the access to its data centers, Refer Telecom uses the following firewalls: Checkpoint R75/R76,
Cisco ASA 5520/5540/5505 and Cisco FWSM. Cisco ASA supports IPv6 since version 7.0.1, however it
is advisable that we use a more recent version because the earlier versions have some vulnerabilities. If
possible, we should use the version 8.4.2(10), which has the USGv6 certification. The same applies to
the Cisco FWSM, which also has the USGv6 certification on version 4.1(2) but already has IPv6 support
since version 3.1. This firewall is integrated in the Catalyst 6500 model. Cisco FWSM should also be
updated to version 4.1(2) if possible.
As we have seen Cisco solutions are not the only ones used by Refer Telecom. They also use Check-
point firewalls. Checkpoint has IPv6 support in their firewalls since version RGX R60 (except for NGX
R65 HFA 30). However, versions prior to R75.40 require the installation of the package IPv6Pack in
order to improve IPv6 features. The version R75.40 was also the first to obtain the IPv6 Ready Logo
Phase 2 in the category of Core Protocols. However it is advisable that all firewalls are updated to R76
because it has extended IPv6 support, which includes: RADIUS, OSPFv3, BGP, NAT66, IPv6 support
for all communications between security gateways, security management servers and SmartDashboard
and full stateful inspection for IPv6 connections. 1
It is also important to check the performance of the firewalls using IPv6. The payload processing speed
is equal for both IPv4 and IPv6 but the same cannot be said about the IP header. Checkpoint has a 10%
loss in the processing speed of the IPv6 header.
1https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solutionid=sk91140 (last accessed October 1st, 2013)
52 CHAPTER 5. PRACTICAL CASE
5.5.8 Wireless
For the wireless network, Refer Telecom uses Cisco APs. Cisco has two different modes for their APs:
Autonomous and Lightweight. In autonomous mode each AP has its own configuration and is completely
independent from others APs whereas in lightweight mode we need to have a Wireless LAN Controller
(WLC), which is responsible for the management of all APs connected to it.
Refer Telecom uses their APs in Lightweight mode and has a WLC from the 4400 series. This equipment
is able to support IPv6 in "pass through" mode. This means that even if there is no IPv6 implementation
on the WLC, it will be able to forward packets between equipment. WLC should be used with the release
6.0 at least, because before this release it is not possible to implement any security measurements nor
to have IPv4 and IPv6 users in the same WLAN.
5.5.9 FaxMail and SMS
Refer Telecom uses the service of FaxMail and SMS per Mail to be able to send and receive faxs and
SMSs through the computer. If a user wants to use the SMS service, he just needs to send an email
to an address like [email protected]. Then the email will be delivered to the Exchange
Server (figure 5.12), which will look to what follows the @ and realize that this email must be delivered
to the SMS Center (Movensis SMS Mail 2.1). The SMS Center will now send the SMS through a direct
link to Vodafone, which will deliver the SMS to the number 916543434 just like a regular SMS. This
is what happens if the message is send internally because Microsoft Exchange only does the internal
distribution of emails. To the outside, Refer Telecom uses Anubis.
For the FaxMail service the architecture is extremely similar (figure 5.13), but instead of a SMS Center
they have a Fax server (Solgenia Facsys 5.1) and instead of the link to Vodafone there is a gateway
Figure 5.12: SMS per mail
5.6. MIGRATION PLAN FOR REFER TELECOM 53
to the PSTN. Both these solutions use the IP protocol to communicate, so they need to support IPv6.
Anubis already has full IPv6 support whereas Movensis SMS Mail and Solgenia Facsys only have IPv4
support yet.
5.6 Migration Plan for Refer Telecom
With the costs for the transition to IPv6 estimated and the go ahead signal from the administration, we
can start to define our road map towards IPv6. In order to start it, we need to look at the actual network’s
topology and its components. But first, there are some basic rules that should be followed before we can
proceed. These rules were already defined in the methodology for the migration plan and consist of:
• Every department in the company is informed about the IPv6 migration.
• Give IPv6 training to the IT staff (or else they are not able to migrate the infrastructure and main-
taining it).
• All software developed inside the company takes IPv6 into consideration
• All software and hardware acquired from that moment on must support IPv6. If the equipment
that we want to acquire do not have IPv6 support and no feasible alternatives are available, the
equipment’s suppliers should be questioned about their road map for IPv6. Since we want a full
dual stack network there is no big problem if such equipment is not available because as we have
already seen dual stack will prevail for many years.
• Acquire an IPv6 address block from its LIR.
• Define a lab environment to make some experiences with IPv6. This way, there is no risk to disrupt
the services.
Figure 5.13: FaxMail
54 CHAPTER 5. PRACTICAL CASE
• Learn with others mistakes. If possible analyze similar IPv6 migrations in other companies to avoid
mistakes and problems that may have occurred.
Taking into consideration the size and dimension of Refer Telecom’s data centers it would not be feasible
to create a migration plan for its entire network in this work. Therefore Refer Telecom selected a few of
their most used services and software (DHCP, DNS, Active Directory, IIS and HP Data Protector) and
difined a smaller network environment (figure 5.14), which tries to represent a subset of the real one. It
has 2 internal networks (Porto and Lisbon) interconnected by a Cisco 3750 router. Both these networks
have Windows clients and Lisbon’s network also has a Domain Controller and a Data Protector cell
manager. The domain controller, besides running Active Directory also has DNS and DHCP services
running. The DHCP service is unique and serves the entire network. The connection to the DMZ and
the public network is made through a Checkpoint firewall, which separates the internal network from the
DMZ and the public network. In the DMZ there is a web server and an external DNS server. Both these
services are available for both the internal and public network. To consult the version and the OS of the
equipment and services, refer to table 5.8.
This network has the following features:
• Both office networks are able to communicate between them
• Porto office has only personal computers whereas Lisbon office has personal computers as well
as the Domain Controller running AD, DHCP and Internal DNS services and a data protector Cell
Manager
• DMZ contains the webserver and the external DNS server. It is contained behind the firewall,
which is their gateway
• Porto and Lisbon networks are interconnected by a router, if someone inside these networks
wishes to communicate with the DMZ or the public network, the router will carry their requests
to the firewall
• The router is the default gateway for Porto and Lisbon offices
Table 5.8: Services and equipment
5.6. MIGRATION PLAN FOR REFER TELECOM 55
Figure 5.14: Network to migrate
• The Lisbon office has free access to the DMZ and to the public network, whereas Porto office can
only reach the webserver via HTTP or HTTPS. It is also possible to ping the webserver via Porto.
• Both machines in the DMZ have a restricted access to the internal networks; they are only allowed
to establish connections with the cell manager in order to perform backups. The firewall also allows
DNS queries originating from the external DNS server to reach the internal network.
• The personal computers in Porto and Lisbon offices should obtain an IP address via the DHCP
server present in the Lisbon Office.
• All servers have static IP addresses except for the External DNS server.
• BIND server should obtain an IP address via DHCP.
• Internal clients must use the internal DNS server to resolve hostnames and IP addresses, if no
records are found for a specific name, the request should be forward to the external DNS server.
• External clients must use the external DNS server to resolve hostnames and IP addresses.
• The internal DNS server is the master for the rt.local zone.
• The external DNS server is the master for the ist.local zone.
• The management of the firewall is performed via the IP address 192.168.1.100.
• The data protector service should be able to perform backups in every device of the network.
• All machines should be able to reach the web server.
56 CHAPTER 5. PRACTICAL CASE
Our goal is to achieve a successful IPv6 migration. So, how can we achieve it? Since we want a transition
based on dual-stack we must assure that all services and equipment in the network can communicate
through IPv4 and IPv6. After all the steps presented in the beginning of this chapter have been fulfilled
we can proceed. As mention earlier there are 6 phases to complete in order to obtain a full IPv6
transition:
• Upgrading or replacing equipment without IPv6 support
• Addressing Plan
• Phased deployment of IPv6 into the network
• Treat network’s dependencies without IPv6
• Partial decommissioning of IPv4
• Decommissioning of IPv4
5.6.1 Upgrading or Replacing Equipment Without IPv6 Support
Here is where the document about the estimation of costs comes in handy. This document contains
information about all the necessary steps to assure IPv6 support in all network equipment and services.
After all the recommendations presented in the document are fulfilled we can move on to the next phase.
If we compare all the equipment and services included by Refer Telecom in our network with the rec-
ommendations made in the elaborated document, we can see that everything already has IPv6 support.
However, if there are newer versions with extended IPv6 support, the device or service should be up-
dated. In our case we should update Checkpoint from R75.40 to R76 because the R75.40 version has
some limitations, like the inability to perform management over IPv6. To see a more detail explanation,
check the firewalls section in the elaborated document.
5.6.2 Addressing Plan
Enabling IPv6 in the network is a process that must be carefully planned. It should follow a predefined
order and not a random order. Some equipment and services like routers and firewalls must be enabled
before any others. But there is something that should be done before all this. If we look at figure 5.14
we can see that all devices have IPv4 addresses, so a good start will be to create an addressing plan for
IPv6. We do not want to give random IPv6 addresses to the migrated hosts. In fact, we should create
an addressing plan as efficient as possible. Thus, we will benefit from many advantages:
5.6. MIGRATION PLAN FOR REFER TELECOM 57
• Security policies are easier to implement
• Addresses are easier to trace
• The Addressing plan is scalable
• Enables a more efficient network management
We will use the following address space: 2001:da12:1234::/48. Therefore we have 16 bits to create
subnets since the last 64 bits are used for addressing hosts. Thus, we can use all the prefixes from
2001:da12:1234:0000::/64 until 2001:da12:1234:ffff::/64 to create subnets, in a total of 65536 subnets.
There are already diverse documents created to help network engineers create their own addressing
plans, in this work we use the following one: Preparing an IPv6 Addressing Plan1. We will create our
addressing plan based on locations, so we need one subnet for Porto office, one subnet for the Lisbon
office, one subnet for the DMZ, and one subnet for the public network. Now we must determine how
many bits we need from the 16 available for our addressing plan. Looking at all the bits available (128)
it is common to think "why should I bother not wasting a few more bits when there are 128 available?"
The answer is quite simple: we need to assure that our plan can be extended in the future in a scalable
manner granting us efficiency. To find out how many bits we need, do as follow:
1. Determine the number of locations or user types within the organization (we use locations).
2. Increase the number by one (backbone purposes) .
3. Add one number for each network without a fixed location, like VPNs or tunnels.
4. Add one or two groups for future expansion.
5. To create a practical addressing plan we will round up our number to the nearest power of 2.
By following these steps we end up with 4 locations in step 1. Step 2 adds another number and step
3 does not change our number since we have neither VPNs nor tunnels. For last step 4 adds 2 more
number making a total of 7. Now we need to round up our number to the nearest power of 2, ending up
with 3 bits. These 3 bits allows us to create 8 subnets (one more than we need) leaving 13 available bits.
These bits left available can be used to define different subnets for different types of users for example
(in our network environment this is not taken into consideration). Since we have so many bits left we
can use them to improve legibility of IPv6 addresses. As we know 4 bits represent one hexadecimal
number in an IPv6 address, so instead of 3 bits we can take one bit from the available ones and use
4 bits to create subnets. This way we can create subnets from: 2001:da12:1234:0000::/64 through
2001:da12:1234:f000::/64. Table 5.9 shows the subnets that we will be using.1http://www.ripe.net/lir-services/training/material/IPv6-for-LIRs-Training-Course/IPv6_
addr_plan4.pdf (last accessed October 1st, 2013)
58 CHAPTER 5. PRACTICAL CASE
Table 5.9: Subnets
For the hosts with static addresses like servers we can use a similar policy to the one used in IPv4.
Use the firsts or the lasts addresses available, for example: 2001:da12:1234:1000::1. The network
administration responsible for the migration is free to choose the method that fits best in his mind.
However ,there is another alternative to the addressing plan present above. We may prefer to create an
addressing plan that explicitly matches the correspondent IPv4 network. Since all our IPv4 networks are
/24 it is extremely easy to create a direct map between an IPv4 address and an IPv6 address. For exam-
ple, if we have a network 192.168.1.0/24, we can use penultimate number to perform this mapping. So
the address 192.168.1.0/24 will correspond to the IPv6 address 2001:da12:1234:1::/64. For equipment
using static addresses like routers or servers we can also use the last number of the IPv4 address in the
IPv6 address. So, a server with the IP 192.168.1.254 will have the IP 2001:da12:1234:1::254 for IPv6.
This method is very useful for a network administrator, since he can look at an IPv6 address and imme-
diately associate that address with the respective IPv4 address. As we know is way easier to remember
an IPv4 address than an IPv6 address. Without this method it is not possible for a network engineers
in big environments to know to what machine a given IPv6 address belongs without consulting informa-
tion regarding the list of IP addresses. Taking this into consideration we will use the mapping of IPv4
addresses into IPv6 addresses for our network. Figure 5.15 shows the IPv4 and the respective IPv6
addresses of all devices that were configured statically in IPv4 and that need to be configured now for
IPv6. The mapping of addresses is very interesting regarding servers and routers but for common hosts
is almost irrelevant. These hosts will get IPs from DHCPv6 without any relation to the correspondent
IPv4 addresses.
When we look at the subnets used we may find odd that a link which only requires 2 addresses has a
/64 prefix, however these are the IETF recommendations. A subnet should never be higher than a /64.
Now that we have IPv6 addresses to distribute through our machines, we can proceed to the next step.
5.6.3 Phased Deployment of IPv6 into the Network
The deployment of IPv6 through the network should be done according to this order:
5.6. MIGRATION PLAN FOR REFER TELECOM 59
Figure 5.15: IPv4/IPv6 addresses
1. Routers, firewalls and switches
2. Basic network services
3. Workstations in the internal network
4. Servers and services in the internal network
5. DMZ
We should focus first on the internal network and once the internal network is fully IPv6 enabled and
monitored we can start enabling IPv6 in the DMZ. This order should be followed for two reasons. The first
is that by enabling IPv6 in just one part of the network it is easier to perform and monitor the migration.
The second reason regards the DMZ itself. The DMZ should be left for last because it requires special
attention in terms of security. Since the DMZ is open to the outside, a simple mistake could compromise
the entire network whereas the internal network cannot be reached from the outside. Thus a mistake
here would not have the same impact as one in the DMZ.
5.6.3.1 Routers, Firewalls and Switches
Routing and security devices should always be the first devices where IPv6 is enabled. First of all, IPv6
must be enabled on the only router present in the network. The router has to be able to respond to any
request coming either through IPv4 or IPv6. The same thing goes for the firewall. It has to be configured
to process IPv6 packets with the same rigor of IPv4 packets. All the existing firewall rules must be
adapted to IPv6 and since Checkpoint cannot inspect extension headers, (except for the fragmentation
one) any packets containing these headers should be dropped.
60 CHAPTER 5. PRACTICAL CASE
Since the switches only work on layer 2, there is no real impact from IPv6 in them. The only part
where the IP protocol is used is for management, so we will need to configure IPv6 addresses in their
management interfaces.
5.6.3.2 Basic Network Services
After enabling IPv6 in the firewall and in the router we need to enable basic network services like DNS
and DHCP before having concerns with other devices. There is no reason for migrating services and
hosts to IPv6 who rely on DNS and DHCP to work, before those services are IPv6 enabled. As we have
seen before both of these services run on a single machine, together with Active Directory. Once this
machine is IPv6 enabled, we should be able to start creating AAAA records. After that, we can move on
to DHCP and activate DHCPv6. Active Directory should have no problem working over IPv6 after the
machine and the DNS server are configured for IPv6.
5.6.3.3 Workstations in the internal network
All the workstations in the internal network run Windows 7. IPv6 should be enabled on every PC of the
network and should be configured to get an IP address via DHCPv6.
5.6.3.4 Servers and Services in the Internal Network
Looking at our internal network we can see that in this phase we should enable IPv6 in Data Protector
Cell Manager. Data protector works with names not with IP addresses, so as long as our DNS server is
well configured and the system where the cell manager is running has an IPv6 address, the cell manager
should have no problems working with IPv6 instead of IPv4. Besides the cell manager, the media agent
(both the cell manager and the media agent run in the same machine)and the system on which we want
to run a backup must also be IPv6 enabled and have their names registered in the DNS server. Thus,
we will be able to perform backups, regardless of the version of the Internet Protocol used.
5.6.3.5 DMZ
In the DMZ there are two servers that need to be migrated. One runs the web server and the other
runs BIND as the external DNS server. To allow connection to the web server over IPv6 we just need to
enable IPv6 on the machine hosting the web server. For BIND we need to go a bit further, since BIND
has to be configured to handle AAAA records. Since BIND is a DNS Server we have to enable IPv6 in it
before we proceed to the web server.
5.6. MIGRATION PLAN FOR REFER TELECOM 61
In the end of this phase all equipment and services should have been configured with dual stack. All
network features supported for IPv4 should now be supported using IPv6. If there is any feature of the
network who is not working properly over IPv6, we have to pinpoint the respective feature and deal with
it in the next phase.
5.6.4 Treat Network’s Dependencies Without IPv6
As we have seen before, every component of the network has support for IPv6, therefore we should be
able to have the entire network working over IPv6 with no limitations. However, it is possible that when
the migration is putt into practice or the testbed is elaborated, we find some special features presented
in the IPv4 network that are not supported in IPv6. In this case we have to find a plausible alternative.
The alternatives could be:
• Find out if the equipment will have support for that feature any time soon
• Replacing the equipment for another with the same characteristics but with the required feature
• Replacing the equipment for another with similar characteristics and support for the required fea-
ture
• Find a way to avoid this problem
• Decommissioning of the equipment
5.6.5 Partial Decommissioning of IPv4
Once the IPv4 traffic is no longer relevant (somehow compared to today’s IPv6 traffic), we should take
measures to reduce the company concerns with IPv4 usage. Therefore, IPv4 should first be removed
from workstations and then from servers. In order to be able to reach the few IPv4 users spread across
the public network, we need to implement NAT64 and DNS64. Here we can use a solution like the one
provided by A10networks 1, which is exactly what we need. So by adding this device to the DMZ, it will
be possible for both internal and external IPv6 clients to access IPv4 hosts and servers. Although this
solution is made to allow IPv6 users to access IPv4 content and not the other way around, this is not an
immediate requirement, because nowadays there is no IPv6-only content. This will only be a reality in
the next decade probably, so by then, this solution from A10networks as well as many others will also
provide NAT46 services. As the name suggests, NAT46 is the opposite of NAT64, it allow IPv4 users to
access IPv6 content.1http://www.a10networks.com/products/axseries-NAT64_DNS64.php (last accessed October 1st, 2013)
62 CHAPTER 5. PRACTICAL CASE
5.6.6 Decommissioning of IPv4
When IPv4 is no longer used it is time to proceed with its decommissioning:
• NAT64, NAT46 and DNS64 should be discontinued since they are no longer needed.
• IPv4 should be removed from the firewall and the router.
• IPv4 addresses should be returned to the respective LIR.
After completing this last phase we have finally completed our IPv6 migration.
Chapter 6
Experimental Validation
6.1 Introduction
In this section we will test the migration plan defined in the previous chapter. To do that we created a lab
environment as close as possible to the network present in figure 5.14.
6.2 Validation
Due to space and equipment limitations we will have to create a virtual network to simulate the real one.
To do it, we will use VMware ESX 5.1. Since there was no physical router available for this project, we
had to find an alternative. The alternative was to emulate the router using Graphical Network Simulator
3(GNS3). A Virtual Machine (VM) running CentOS was used to implement GNS3. To simplify the lab
environment we will create only one host in Porto and one in Lisbon. Table 6.10 shows the VMs and
the Operating System (OS) used as well as the version of each service running on them.
As we can see the only differences to the real network are the router used and the version of the firewall.
Table 6.10: VMs used
63
64 CHAPTER 6. EXPERIMENTAL VALIDATION
In the router’s case this is due to equipment limitation whereas in the firewall’s case we used the R75.40
version by request of Refer Telecom. The implemented network is fully contained within the ESX host.
So the first thing to do is to configure the ESX host. As we can see in figure 5.14 the network includes
VLANs, so we will need to use the Vswitch functionality of VMware. There are three different types
of VLAN tagging in an ESX host: EST (External Switch Tagging), VST (Virtual Switch Tagging), VGT
(Virtual Guest Tagging). Given that we will not be using an external switch and we do not want the VMs to
perform the tagging by themselves, we will use VST. In VST all tagging is performed by the virtual switch
before leaving the ESX host, which is clearly the best option if we want to simulate a real environment in
a fully contained network within an ESX host. The term "real environment" was used because generally
in a network all the VLAN tagging is performed by the switch/router and not by the machine itself. In
order to respect the given VLAN configuration we had to pair the VMs network interfaces like Appendix
A.26 shows.
6.2.1 IPv4 Network
With the ESX configuration complete we can proceed to configure all the virtual machines required until
we have a fully operational IPv4 network.
6.2.1.1 Configuration of the Router
Since the router is emulated with GNS3 (figure 6.16), we must create a TAP and a bridge interface in
the VM responsible for running GNS3 for each interface on the router. These interfaces are needed to
assure that the router inside GNS3 is able to communicate with the VM and therefore with the network
within ESX.One more thing is needed in the ESX host, we have to enable promiscuous mode in our
Vswitch. The reason is simple, we are running a virtual router on a VM and the ESX host has no idea
that this is happening. Therefore without promiscuous mode enabled the network would not allow ARP
packets to go back into the router, breaking communication.
With the VM configuration complete, it is necessary to configure the router itself. First of all we should
define Porto and Lisbon networks and their respective VLANs:
• 192.168.1.0/24 in VLAN 100 as the Lisbon Office
• 192.168.2.0/24 in VLAN 101 as the Porto Office
As we can see in figure 6.16 the router uses only one phisycal interface for Porto and Lisbon networks,
therefore besides the VLAN configuration on the Vswitch we also have to define the VLANs in the switch
and configure the router to forward requests coming from one VLAN to another. To add VLANs to the
6.2. VALIDATION 65
Figure 6.16: GNS topology
switch we needed to configure port 1 and port 2 in access mode with VLAN ID 100 and 101 respectively.
Port 3 must be in trunk mode to allow traffic from any VLAN in that link (figure 6.17). The next step
was to configure the link to the firewall, which is directly connected to the DMZ and the public network.
For this link we used the 192.168.4.252/30 network. Since no routing protocols are used the router only
needs to have configured a default route to the firewall.
6.2.1.2 Configuration of the VM Domain Controller
Domain controller is a very important part of the network since it contains three of the network most
important services: AD, DHCP and DNS. The machine was configured with the IP address 192.168.1.1
and has the router as the default gateway. The DHCP server in this machine is responsible to serve 3
networks: Lisbon, Porto and DMZ. To allow the DHCP server to serve requests coming from Porto and
Figure 6.17: Switch configuration
66 CHAPTER 6. EXPERIMENTAL VALIDATION
DMZ it was necessary to configure the router and the checkpoint as relay agents. The DNS service was
configured to be the master of the rt.local zone.
6.2.1.3 Configuration of the Windows Hosts
As already mentioned, hosts in Lisbon and Porto were configured using a DHCP Server
6.2.1.4 Configuration of the IIS
Our web server was configured with the static IP address 192.168.3.50 in the DMZ. The firewall is its
default gateway.
6.2.1.5 Configuration of the Firewall
Static routing was configured in the firewall to create routes between Porto, Lisbon, DMZ and the public
network. The firewall was also configured as the default gateway for the DMZ. As we can notice in
figure 5.14 the firewall reaches Lisbon and Porto networks through the router whereas for the DMZ and
public network it is directly connected. As we know, by default Checkpoint and any other firewall drop all
traffic, so we need to configure rules to allow network traffic to pass through the firewall. Lisbon office
should be able to get to the web server without any restrictions whereas Porto should only be able to
get to the web server through http or https. Regarding BIND, it is necessary to allow DNS queries to
flow between BIND and Windows DNS server. The management of checkpoint should be made through
the IP address 192.168.1.100. To make all this possible we had to implement in checkpoint the rules
present in Appendix B.27.
6.2.1.6 Configuration of External DNS
BIND was configured to be the master of the ist.local zone and to serve DNS requests coming from the
internal network as well as requests from the public network. It is important to state that the internal
DNS forwards unknown requests to this DNS server. This server does not possess a static IP address
as most of the servers in a DMZ possess, in fact it has an IP address from the DHCP server in Lisbon
office.
6.2. VALIDATION 67
6.2.1.7 Configuration of Data Protector
The components of Data Protector were already exhaustively detailed previously so there is no need to
repeat all the concepts. A Cell Manager was installed in a Windows Server 2008 R2 in Lisbon office
to control all the backups in the network. Since it is a central part of Data Protector it was obviously
configured with a static IP address. The Cell Manager will also act as a Media Agent, so it is responsible
for mediating the communication between the system being backed up and the system where the backup
will be stored. However, since we do not have any storage device the backups will be storage in the
Media Agent itself. For the systems that we want to backup we have to install a data protector agent on
them (remotely or locally).
One important note to take is that all the services and equipment used, have IPv6 support. Figure 6.18
shows the implemented network with all the correspondent IP addresses.
6.2.2 IPv6 Network
With the IPv4 network implemented it is time to test our migration plan. The objective is to achieve a full
dual-stack network by following the migration plan recommendations. So we will focus on the third point
of our migration plan: phased deployment of IPv6.
As we described in the migration plan there are 5 stages to deploy IPv6:
1. Routers, firewalls and switches
2. Basic network services
3. Workstations in the internal network
4. Servers and services in the internal network
5. DMZ
6.2.2.1 Routers, Firewalls and Switches
Since the router is emulated with GNS3 we need to enable IPv6 on CentOS (machine where GNS3 is
running) and define IPv6 addresses for the bridge interfaces used by the router.
After that we can move on to the actual topology. As in any network, the router is the first device where
IPv6 should be enabled. By default the Cisco 7200 comes with IPv6 turned off, so we need to enable
it. Then all three interfaces must be configured with IPv6 addresses and the IPv6 static routes must be
68 CHAPTER 6. EXPERIMENTAL VALIDATION
Figure 6.18: Implemented network
defined. The static routes are exactly the same as in IPv4 but with their correspondent IPv6 addresses.
The full configuration of the router can be found in Appendices A.24 and A.25.
Remember that the switch is also emulated with GNS3 so it is not possible to add an IP address to its
management interface. However when we implement IPv6 in the real network, this must be done.
For the Checkpoint R75.40 we need to enable IPv6 through the browser interface. After that we are able
to configure IPv6 in the firewall. As it happened in the router, we also have to configure the network
interfaces and the static routes for IPv6. With this done, we can move to the creation of IPv6 rules in
the firewall. In order to secure the network for both IPv4 and IPv6 threats, all the rules defined for IPv4
must be replicated to their correspondent IPv6 rules. Creating these new rules is just like creating rules
for IPv4. We just need to create IPv6 hosts instead of IPv4 hosts. By request of Refer Telecom, we
will add a rule to only allow users in Lisbon Office to perform remote desktop access to the web server
through IPv6, all the rest remains the same. The full list of rules implemented in the firewall can be seen
in Appendix B.28.
As we have seen before, IPv6 has its own special features that must be dealt with, namely extension
headers. In order to protect the network, these packets cannot be ignored. By default checkpoint
drops all extension headers except the fragmentation header 1 and we will leave it that way. Regarding
fragmentation, if checkpoint receives a packet that cannot be transmit due to an MTU issue, an ICMP
is sent back to tell the client to send a smaller packet. As of R75.40 it is also possible to block routing
headers with type 0. This parameter is also enabled by default and we will also leave it that way. It
is important to notice that allowing extension headers through the firewall may not be a good idea,
since checkpoint does not inspect any extension header except fragmentation. It can only allow or1https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_
doGoviewsolutiondetails=&solutionid=sk39374 (last accessed October 1st, 2013)
6.2. VALIDATION 69
block them. Thus, extension headers besides the fragmentation headers should only be allowed if
it is absolutely necessary. Unfortunately R75.40 does not support IPv6 for communications between
Security Gateways, Security Management Servers, and SmartDashboard. So firewall management can
only be done over IPv4.
6.2.2.2 Basic Network Services
With the router and the firewall ready to support an IPv6 network it is time to enable basic network
services like DNS and DHCP. In our network these services run on a single machine, together with
Active Directory. So the first step is to enable IPv6 in this machine. To enable IPv6 in Windows Server
2008 R2 we just need to give the machine a static IPv6 address. Accordingly to the addressing plan
defined, this address will be 2001:da12:1234:1::1. There is however a small problem in Windows when
we configure a static IPv6 address, if there is a DHCP server in the network, a Windows machine
with a static IP address will also obtain an IP address via DHCP. To solve this problem we must turn
off Router Discovery on every Windows Server with a static IPv6 address configured, by issuing the
command: netsh interface ipv6 set interface "Local Area Connection" routerdiscovery=disabled
in the command line.
With this done the machine is ready to connect to IPv6 devices and provide services through IPv6.
Active Directory does not need any additional configuration to work with IPv6.
The DNS server from Windows Server 2008 R2 is extremely easy to configure for IPv6. In fact we just
need to add AAAA records instead of A records for IPv6 hosts. We also needed to create the respective
reverse lookup zones to allow the server to retrieve a name from an IPv6 address. The names used are
the same as in IPv4 (figure 6.19). However, we added specific IPv6 names for testing purposes.
The configuration of the DHCP server for IPv6 is a bit trickier. As we know, the routers are now re-
sponsible for sending RAs messages (Router Advertisements) , who among other tasks are responsible
for telling the hosts how they are going to get an IP address (DHCP, SLAAC or static). So we have to
configure both the router and the DHCP server. The DHCP server from Windows Server 2008 R2 is
ready to be configured for IPv6. We just need to create the respective pools (figure 6.20). There are still
some differences in IPv6, DHCP does not propagate information like the default gateway for the host.
In IPv6, router advertisements are used for these functions. Other small difference is that we can no
longer define smaller ranges of addresses like we did in IPv4. Nonetheless it is still possible to create
reservations, which serve the same purpose.
The configuration of the DHCP server for IPv6 is fairly simple if we know how to configure it for IPv4.
However if we configure an IPv6 pool but forget to configure the router accordingly, things will go wrong.
By default a Cisco router will send RAs with the Autonomous (A) flag set to 1, telling the hosts that they
70 CHAPTER 6. EXPERIMENTAL VALIDATION
Figure 6.19: DNS resolutions
should configure a stateless address based on the advertised prefix. Therefore hosts will get stateless
and stateful IPv6 addresses leading to connectivity problems. To correct this problem we must configure
the router to tell the hosts that they should get an IPv6 address through a DHCP server. There are three
types of flags to help hosts know how they are going to get an IP address: A (Autonomous), M (Managed
Address) and O (other stateful configuration). These bits are part of the neighbor discover feature from
ICMPv6. We already saw above what the A bit does but not M and O bits. If the M bit is set to 1 the host
is instructed to get and IP address through a stateful configuration protocol (DHCPv6). If the O bit is set
to 1 that means the host will get other configurations from a stateful configuration protocol (DHCPv6).
Table 6.11 shows us the different types of combinations and their repercussions. By default the A flag
is set to 1 while M and O are set to 0.
By looking at table 3 we can see 2 options that satisfy our requirement to have our hosts receiving IPs
from a DHCP server. The first option is the A bit set to 0 and the other two set to 1, and the other option
is only the M bit set to 1. However the DHCP server should also distribute other information to hosts like
the location of the DNS server, so we should configure the router with both the M and O bits set to 1. To
end our DHCP configuration on the router we need to configure the DHCP relay agent just like we did in
IPv4, so that the hosts in Porto office can get an address from the DHCP server in Lisbon.
6.2. VALIDATION 71
Figure 6.20: DHCP pools
Table 6.11: Different options to configure an IPv6 address in a host
72 CHAPTER 6. EXPERIMENTAL VALIDATION
6.2.2.3 Workstations in the Internal Network
All the workstations in the internal network run Windows 7. By default Windows 7 already has IPv6
enabled, so if the DHCP server is well configured our Windows hosts will get an IPv6 address. Windows
7 as well as Windows Server 2008 and later versions prefer IPv6 over IPv4 if both versions are config-
ured. So if Windows makes a DNS query, and both type of records (A and AAAA) are returned, it will
choose IPv6 to make the connection. However, even with dual stack enabled, all Windows systems use
IPv4 to make DNS queries. If we want to make these queries over IPv6 we can turn off IPv4. If IPv6 is
disabled we just need to open the network and sharing center, click on local area connection and click
on properties. There you need to fill the Internet Protocol version 6 (TCP/IP) check box in the networking
tab. Then using wireshark we should be able to see the messages trade between the DHCP server and
the client before the client get an IPv6 address (figure 6.21).
6.2.2.4 Servers and Services in the Internal Network
The Cell Manager, as already referred, is also running under Windows Server 2008 R2, therefore we
must enable IPv6 in it, if IPv6 is not yet enabled. The server must be configured with the static address
2001:da12:1234:1::2/64.
No additional configurations are required to allow Data Protector to work with IPv6 because as we
already explained, Data protector works with names not with IP addresses. Therefore we are now able
to perform backups over IPv6 to any client who has an IPv6 address and is registered in the DNS server.
Appendix C.29 shows Data Protector performing a backup to the web server over IPv6. One important
note is that Data Protector favors IPv6 over IPv4. As expected this is valid for both Windows and Linux
hosts since Data Protector relies on DNS to communicate with the backup target and both of those
operating systems have this behavior by default. So if both types of records are available for a certain
query, it will choose the one from IPv6.
By having dual stack implemented on the network we gain more resilience. Let’s look at the example
provided by data protector: if data protector tries to initiate a backup over IPv6 and it fails for some
reason, it will be able to switch to IPv4 and perform the backup over IPv4. To test this scenario we created
a rule in the firewall to drop any IPv6 packets with destination address equal to 2001:da12:1234:3::50
or 2001:da12:1234:1::2 and destination port equal to 5555 or between 18000 and 18050 (ports used by
Figure 6.21: DHCPv6 messages
6.2. VALIDATION 73
Data Protector). As we can see in Appendix C.30, Data Protector is able to perform the backup over
IPv4 after failing to establish a connection over IPv6. The contrary would also be possible, using IPv6
after failing to connect through IPv4.
6.2.2.5 DMZ
In the DMZ there are two servers that need to be migrated. One runs the web server and the other runs
BIND as the external DNS server. The web server runs under Microsoft Server 2008 R2 and BIND runs
under CentOS 6.
To allow clients to reach the web server through IPv6 we just need to enable IPv6 in Microsoft Server
2008 R2 as shown before with the IPv6 address 2001:da12:1234:3::50.
Like Windows, CentOS prefers IPv6 over IPv4. If a query made to a DNS Server returns both types of
records, A and AAAA, CentOS will use IPv6 to make the connection. We observed this behavior after
configuring IPv6 on CentOS. To configure it we must edit two configuration files: /etc/sysconfig/network
and /etc/network-scripts/ifcfg-eth0 (the number depends on the configuration). In /etc/sysconfig/net-
work the following lines must be added:
• IPV6_DEFAULTGW=2001:da12:1234:3::254
• NETWORKING_IPV6=yes
In /etc/sysconfig/network-scripts/ifcfg-eth0 we must add this line to enable IPv6 in an interface:
• IPv6INIT=yes
However, this server received its IPv4 address through the DHCP server in Lisbon, which means that
the firewall needs to have the DHCP relay function activated. Here comes the bad news, checkpoint
R75.40 does not support DHCPv6 relay, so it is not possible for a device in the DMZ to get an IPv6
address from a DHCP server outside its local network. To solve this problem we will use for now a static
IPv6 address. To do that, add the following line to the /etc/sysconfig/network-scripts/ifcfg-eth0 file:
• IPV6ADDR=2001:da12:1234:3::100
With the server able to communicate over IPv6 it is time to enable IPv6 in BIND. First we have to edit
the /etc/named.conf file and make sure that the following line is present:
• listen-on-v6 { any; }
74 CHAPTER 6. EXPERIMENTAL VALIDATION
Then we need to add IPv6 records to our BIND Server. To do this, we should edit our forward zone and
reverse lookup zone files just like we did in IPv4 but now we should add records of type AAAA instead
of type A. Figure 6.22 shows the forward lookup zone required to allow BIND to correctly respond to
requests coming from both IPv4 and IPv6. Once BIND configuration is finished, we can configure the
internal DNS server to forward unknown requests to it. Remember that, since BIND is a DNS server we
had to configure it before the web server.
With all these configurations complete we ended up with the network present in figure 6.23.
6.2.3 Identification of Problems
In the description of the network for which we created a migration plan, we made a list with all the
features of the network. To implement the entire network and its features we used VMware, so now we
will see if those features are supported for both IPv4 and IPv6 (table 6.12 ).
There were only 2 features that we were not able to implement in IPv6: firewall management over IPv6
and DHCPv6 relay. In both cases checkpoint R75.40 does not have IPv6 support for these features.
Resolving the first problem (firewall management over IPv6) is very simple. We just need to upgrade our
Checkpoint from R75.40 to R76. R76 brings several new IPv6 enhancements and managing the firewall
using IPv6 is one of them.
The problem concerning DHCPv6 relay is a bit harder to solve because none of Checkpoint firewalls has
DHCPv6 relay implemented. Therefore we must find an alternative and these are the ones we can use:
• Find and alternative firewall who support DHCPv6 relay
• Implement a DHCP server in the DMZ
Figure 6.22: BIND forward lookup zone
6.2. VALIDATION 75
Figure 6.23: IPv6 enabled network
• Use static addressing instead of DHCP
We will use static addressing just like we used in the testbed because it is the more economic and simple
solution. This way we do not need to replace the firewall nor add a new machine to the DMZ. And since
we are talking about a DNS server, we should remember that is considered a good practice to use static
addresses in network servers.
In this network we did not have any trouble with equipment without IPv6 support, but imagine if our web
server did not support IPv6 and we could not replace it for another. In fact, the solution for a problem
like this is fairly simple. We could use a load balancer with NAT64/DNS64 incorporated like the one we
have seen before 1. By using this load balancer as the default gateway for the DMZ it would be possible
for any IPv6 client to access our IPv4 web server.
1http://www.a10networks.com/products/axseries-NAT64_DNS64.php (last accessed October 1st, 2013)
76 CHAPTER 6. EXPERIMENTAL VALIDATION
Table 6.12: IPv4 vs IPv6 features
Chapter 7
Conclusion
IPv6 will replace IPv4 as the predominant Internet Protocol in a near future. It could take 5, 10 or 20
years but this is inevitable. Organizations around the globe must be prepared for this change and make
sure they have the "know how" to be able to succeed when they decide to migrate to IPv6.
We have shown the differences between the two protocols and the new challenges brought by IPv6 not
only to service providers but to enterprises as well. The world is finally understanding the need to change
and the diversity of new horizons that IPv6 will bring. IPv6 traffic as been growing exponentially in the last
years and with the investment being made by ISPs and organizations worldwide this positive trend will
continue in the next years. Therefore, many companies already started to plan their transition towards
IPv6, however this number is yet very low when compared to companies where nothing has been done
to prepare the company’s network infrastructure to IPv6. These companies are the main target audience
for our work, since this dissertation proposes a generic migration process for a company that pretends
to introduce IPv6 in its network. Network engineers responsible for migrating their companies networks
to IPv6 can use the migration process proposed here as a reference/guideline to help them in this task.
This migration process is comprised of 9 steps:
• Analysis of the current situation
• Present a study focused on the migration impact for the company
• Survey of the enterprise’s network
• Analyse IPv6 support from ISPs
• Estimate the costs of migrating the company’s network
• Migration plan
77
78 CHAPTER 7. CONCLUSION
• Testbed
• Identify problems
• Final implementation
After the development of the migration process, we applied it to a subset of the data centers’ network
of Refer Telecom and created a lab environment representing a subset of this network to validate our
migration process. By implementing our migration process in a real scenario, we were able to see
its usefulness but also the need to adapt it to the network and organization in question. Every single
company has its own network specifications and rules, so we must be able to adapt the defined migration
process to each individual case.
Unfortunately, due to the size of Refer Telecom, it was not feasible to create a migration process for its
entire network in this dissertation. Although the first 5 points of the migration process were made for
the whole network, it was not possible to do the same for the migration plan (point 6 of the migration
process). Instead Refer Telecom selected a few of their most used services and equipment and created
a subset of its network to be used in our plan. So the migration plan was created for this smaller network
defined by Refer Telecom. With the help of virtualization software we were able to replicate this network
and prove the effectiveness of our plan.
Even without a migration plan for the entire network, it is now possible for Refer Telecom to proceed
with IPv6 migration in their data centers with the help of this work. If Refer Telecom wishes, the next
steps for this work will be the definition of a migration plan for the entire network and then the actual
implementation of IPv6 in their data centers.
Bibliography
[1] S. V. Limkar, R. K. Jha, and S. Pimpalkar, “Ipv6: issues and solution for next millennium of
internet,” in Proceedings of the International Conference & Workshop on Emerging Trends in
Technology, ser. ICWET ’11. New York, NY, USA: ACM, 2011, pp. 953–954. [Online]. Available:
http://doi.acm.org/10.1145/1980022.1980226
[2] R. Guérin and K. Hosanagar, “Fostering ipv6 migration through network quality differentials,”
SIGCOMM Comput. Commun. Rev., vol. 40, no. 3, pp. 17–25, Jun. 2010. [Online]. Available:
http://doi.acm.org/10.1145/1823844.1823847
[3] E. Davies, S. Krishnan, and P. Savola, “IPv6 Transition/Co-existence Security Considerations,”
RFC 4942 (Informational), Internet Engineering Task Force, Sep. 2007. [Online]. Available:
http://www.ietf.org/rfc/rfc4942.txt
[4] Srinivasan.Nagaraj, B.Kishore, K. rao, and G. Apparao, “A comparative study of ipv6 statistical
approach,” International Journal on Computer Science and Engineering (IJCSE), vol. 2, pp. 1367 –
1370, 2010.
[5] S. Thomson, T. Narten, and T. Jinmei, “IPv6 Stateless Address Autoconfiguration,” RFC
4862 (Draft Standard), Internet Engineering Task Force, Sep. 2007. [Online]. Available:
http://www.ietf.org/rfc/rfc4862.txt
[6] S. Deering and R. Hinden, “Internet Protocol, Version 6 (IPv6) Specification,” RFC 2460 (Draft
Standard), Internet Engineering Task Force, Dec. 1998, updated by RFCs 5095, 5722, 5871,
6437, 6564. [Online]. Available: http://www.ietf.org/rfc/rfc2460.txt
[7] F. Nada, “Performance analysis of mobile IPv4 and mobile IPv6,” in The International Arab Journal
of Information Technology, vol. 4, no. 2, April 2007, pp. 153 –160.
[8] D. O. Awduchev, “Benefits of IPv6 for Enterprises,” Verizon Business, White paper, 2010.
[9] Y. Wu and X. Zhou, “Research on the IPv6 performance analysis based on dual-protocol stack and
79
80 BIBLIOGRAPHY
tunnel transition,” in Computer Science Education (ICCSE), 2011 6th International Conference on,
aug. 2011, pp. 1091 –1093.
[10] K. Dai, “Ipv4 to ipv6 transition research based on the campus network,” in Proceedings of the 2011
2nd International Symposium on Intelligence Information Processing and Trusted Computing, ser.
IPTC ’11. Washington, DC, USA: IEEE Computer Society, 2011, pp. 199–202. [Online]. Available:
http://dx.doi.org/10.1109/IPTC.2011.58
[11] S. Thomson, C. Huitema, V. Ksinant, and M. Souissi, “DNS Extensions to Support IP Version
6,” RFC 3596 (Draft Standard), Internet Engineering Task Force, Oct. 2003. [Online]. Available:
http://www.ietf.org/rfc/rfc3596.txt
[12] D. Wing and A. Yourtchenko, “Happy Eyeballs: Success with Dual-Stack Hosts,” RFC
6555 (Proposed Standard), Internet Engineering Task Force, Apr. 2012. [Online]. Available:
http://www.ietf.org/rfc/rfc6555.txt
[13] T. Narten, E. Nordmark, W. Simpson, and H. Soliman, “Neighbor Discovery for IP version 6 (IPv6),”
RFC 4861 (Draft Standard), Internet Engineering Task Force, Sep. 2007, updated by RFC 5942.
[Online]. Available: http://www.ietf.org/rfc/rfc4861.txt
[14] L. Wu, D. Hai-xin, L. Tao, L. Xing, and W. Jian-ping, “H6proxy: Icmpv6 weakness analysis and
implementation of ipv6 attacking test proxy,” in Ubiquitous, Autonomic and Trusted Computing,
2009. UIC-ATC ’09. Symposia and Workshops on, july 2009, pp. 519 –524.
[15] Cisco Systems Inc., “IPv6 routing-at-a-glance,” White paper, 2005.
[16] The Federal CIO Council Strategy and Planning Committee, “Planning Guide/Roadmap Toward
IPv6 Adoption within the U.S. Government,” Jul. 2012.
[17] Australian Government, “A Strategy for the Implementation of IPv6 in Australian Government Agen-
cies,” Jul. 2009.
[18] G. V. de Velde, C. Popoviciu, T. Chown, O. Bonness, and C. Hahn, “IPv6 Unicast Address
Assignment Considerations,” RFC 5375 (Informational), Internet Engineering Task Force, Dec.
2008. [Online]. Available: http://www.ietf.org/rfc/rfc5375.txt
[19] E. Nordmark and R. Gilligan, “Basic Transition Mechanisms for IPv6 Hosts and Routers,” RFC
4213 (Proposed Standard), Internet Engineering Task Force, Oct. 2005. [Online]. Available:
http://www.ietf.org/rfc/rfc4213.txt
[20] P.-K. Chen, C.-W. Lu, and Q. Wu, “IPv6 Rapid Deployment in Taiwan Academic Network (TANet),” in
Advanced Communication Technology (ICACT), 2012 14th International Conference on, feb. 2012,
pp. 694 –697.
BIBLIOGRAPHY 81
[21] R. Despres, “IPv6 Rapid Deployment on IPv4 Infrastructures (6rd),” RFC 5569 (Informational),
Internet Engineering Task Force, Jan. 2010. [Online]. Available: http://www.ietf.org/rfc/rfc5569.txt
[22] F. Templin, “Transmission of IPv4 Packets over Intra-Site Automatic Tunnel Addressing Protocol
(ISATAP) Interfaces,” RFC 5579 (Informational), Internet Engineering Task Force, Feb. 2010.
[Online]. Available: http://www.ietf.org/rfc/rfc5579.txt
[23] C. Huitema, “Teredo: Tunneling IPv6 over UDP through Network Address Translations (NATs),”
RFC 4380 (Proposed Standard), Internet Engineering Task Force, Feb. 2006, updated by RFCs
5991, 6081. [Online]. Available: http://www.ietf.org/rfc/rfc4380.txt
[24] S. Frankel, R. Graveman, and J. Pearce, “Guidelines for the Secure Deployment of IPv6(Draft),”
Feb. 2010.
[25] A. Durand, P. Fasano, I. Guardini, and D. Lento, “IPv6 Tunnel Broker,” RFC 3053 (Informational),
Internet Engineering Task Force, Jan. 2001. [Online]. Available: http://www.ietf.org/rfc/rfc3053.txt
[26] A. Durand, R. Droms, J. Woodyatt, and Y. Lee, “Dual-Stack Lite Broadband Deployments Following
IPv4 Exhaustion,” RFC 6333 (Proposed Standard), Internet Engineering Task Force, Aug. 2011.
[Online]. Available: http://www.ietf.org/rfc/rfc6333.txt
[27] M. Bagnulo, P. Matthews, and I. van Beijnum, “Stateful NAT64: Network Address and Protocol
Translation from IPv6 Clients to IPv4 Servers,” RFC 6146 (Proposed Standard), Internet
Engineering Task Force, Apr. 2011. [Online]. Available: http://www.ietf.org/rfc/rfc6146.txt
[28] C. Aoun and E. Davies, “Reasons to Move the Network Address Translator - Protocol Translator
(NAT-PT) to Historic Status,” RFC 4966 (Informational), Internet Engineering Task Force, Jul. 2007.
[Online]. Available: http://www.ietf.org/rfc/rfc4966.txt
[29] Y. Zhai, C. Bao, and X. Li, “Transition from IPv4 to IPv6: A Translation Approach,” in Networking,
Architecture and Storage (NAS), 2011 6th IEEE International Conference on, july 2011, pp. 30 –39.
[30] J. Bound, “IPv6 Enterprise Network Scenarios,” RFC 4057 (Informational), Internet Engineering
Task Force, Jun. 2005. [Online]. Available: http://www.ietf.org/rfc/rfc4057.txt
[31] J. Bound, Y. Pouffary, S. Klynsma, T. Chown, and D. Green, “IPv6 Enterprise Network Analysis - IP
Layer 3 Focus,” RFC 4852 (Informational), Internet Engineering Task Force, Apr. 2007. [Online].
Available: http://www.ietf.org/rfc/rfc4852.txt
[32] O. Dobrijevic, V. Svedek, and M. Matijasevic, “Ipv6 deployment and transition plans in croatia: Eval-
uation results and analysis,” in Software, Telecommunications and Computer Networks (SoftCOM),
2012 20th International Conference on, sept. 2012, pp. 1 –7.
Appendix A
Configurations
A.1 Router Configuration Part 1
A.2 Router Configuration Part 2
A.3 Vswitch VLANs
83
84 APPENDIX A. CONFIGURATIONS
Figure A.24: Vswitch VLANs
A.3. VSWITCH VLANS 85
Figure A.25: Vswitch VLANs
86 APPENDIX A. CONFIGURATIONS
Figure A.26: Vswitch VLANs
Appendix B
Firewall
B.1 IPv4 Rules
B.2 IPv4 and IPv6 rules
87
88 APPENDIX B. FIREWALL
Figure B.27: IPv4 firewall rules
B.2. IPV4 AND IPV6 RULES 89
Figure B.28: Firewalls rules for a dual-stack network
Appendix C
Data Protector
C.1 Successful backup to the web server over IPv6
C.2 Data Protector switching from IPv6 to IPv4
91
92 APPENDIX C. DATA PROTECTOR
Figure C.29: Successful backup to the web server over IPv6
Figure C.30: Data Protector switching from IPv6 to IPv4
