MONOGRAFIA EstudoAplicaçãoTécnicas

Universidade Federal de Ouro Preto
Instituto de Ciências Exatas e Aplicadas

Colegiado de Sistemas de Informação
Estudo da Aplicação das Técnicas de

Transição e Coexistência entre Redes
IPv4/IPv6 na rede do ICEA
Lúcio Flávio de Miranda
TRABALHO DE
CONCLUSÃO DE CURSO
ORIENTAÇÃO:
Theo Silva Lins
Agosto, 2018
João Monlevade/MG
Lúcio Flávio de Miranda
Estudo da Aplicação das Técnicas de Transição

e Coexistência entre Redes IPv4/IPv6 na rede
do ICEA
Orientador: Theo Silva Lins

Coorientador: Marlon Paolo Lima
Monografia apresentada ao curso de Sistemas de Infor-

mação do Departamento de Computação e Sistemas
da Universidade Federal de Ouro Preto como requisito
parcial para obtenção do grau de Bacharel em Sistemas
de Informação
Universidade Federal de Ouro Preto

João Monlevade
Agosto de 2018
M672e Miranda, Lúcio Flávio de.
Estudo da Aplicação das Técnicas de Transição e Coexistência entre Redes
IPv4/IPv6 na rede do ICEA [manuscrito] / Lúcio Flávio de Miranda. - 2018.
104f.: il.: color; grafs; tabs; mapas.
Orientador: Prof. MSc. Theo Silva Lins.

Coorientador: Prof. Dr. Marlon Paolo Lima.
Monografia (Graduação). Universidade Federal de Ouro Preto. Instituto de

Ciências Exatas e Aplicadas. Departamento de Computação e Sistemas de
Informação.
1. Arquitetura de redes. 2. Rede de computador - Protocolos. 3. Comutação

por pacotes (Transmissão de dados). 4. Conectividade (Computadores). I. Lins,
Theo Silva. II. Lima, Marlon Paolo. III. Universidade Federal de Ouro Preto.
IV. Titulo.
Catalogação: ficha.sisbin@ufop.edu.br CDU: 004.7

Dedico este trabalho a todos que de algum modo me ajudaram até aqui.
Agradecimentos
Agradeço primeiro a Deus por tudo.

À minha mãe Maria Aparecida pelo amor e ensimanentos, meu irmão Lucas e
minha namorada Lúcia, pelos incentivos e paciência. Aqui, gostaria de lembrar as pessoas
queridas e que já partiram, minhas tias Ivani Miranda, Zita Miranda e meu pai José Lucas,
que partiu num momento de alegria, um dia após minha apresentação e aprovação no
TCC I. Todos vocês ajudaram a moldar meu caráter.
Aos professores Theo Lins, Marlon Paolo e Vinícius Mota pelos ensinamentos e
orientações recebidos durante a realização deste trabalho. Aos professores Vicente e Gilda
pelas orientações repassadas na banca de avaliação e que tornaram esse trabalho melhor. E
aos demais professores com quem tive oportunidade de compartilhar conhecimento nesta
jornada acadêmica.
Agradeço aos colegas do núcleo de Informática do ICEA, que me ajudaram no
levantamento das informações do cenário de rede do instituto, principalmente ao Plínio com
quem tive mais contato. À Sílvia Regina administradora de edifícios, demais funcionários
do ICEA e à todas as amizades que conquistei na UFOP.
Muito obrigado!
“Os endereços IPv4 existentes estão acabando, e agora?”
Resumo
Estamos inseridos em um período de constante e necessário crescimento da Internet. Em
contrapartida, vivenciamos a escassez dos endereços do Protocolo IPv4 para atender
às novas demandas. Assim, a adoção do IPv6 é primordial para garantir essa evolução.
Neste contexto, conhecer e aplicar técnicas que possibilitem uma transição entre versões,
garantindo o crescimento da Internet e continuidade de serviços tornou-se uma tarefa
árdua, principalmente devido ao atraso vivenciado desde o lançamento dos primeiros planos
de transição. Este trabalho objetiva realizar um estudo das principais técnicas de transição
e coexistência em IPv6, por meio da coleta de dados que possibilitam avaliar o uso aplicado
à arquitetura de rede do ICEA (Instituto de Ciências Exatas e Aplicadas), na UFOP.
Para isso, foi realizado um levantamento do cenário de rede do ICEA, e posteriormente foi
utilizado o software CORE (Common Open Research Emulator) para os testes usando as
técnicas de Pilha Dupla, túneis 6over4 e Generic Routing Encapsulation. Foi executada
também uma implementação de Tunnel Broker, oferecido pela Hurricane Electric, fora
do ambiente de emulação. Os resultados obtidos demonstraram em geral, um melhor
desempenho usando IPv4, que apresentou médias gerais mais baixas em relação ao IPv6.
Estes resultados serviram para avaliar as métricas de Latência, Jitter e Perdas de Pacotes,
o que permitiu uma análise comparativa entre técnicas.
Palavras-chaves: IPv4, IPv6, Técnicas de Transição, CORE, Latência, Perda de Pacotes,

Jitter.
Abstract
We are inserted in a period of constant and necessary growth of the Internet. On the
other hand, we have experienced the scarcity of IPv4 address to meet new demands. Thus,
the adoption of IPv6 is essential to guarantee this evolution. In this context, knowing
and applying techniques that allow a transition between versions, ensuring the growth
of the Internet and service continuity, has become a difficult task, mainly due to the
delay experienced since the launch of the first transition plans. This work aims to carry
out a study of the main techniques of transition and coexistence in IPv6, through the
collection of data that make it possible to evaluate the use applied to the network of the
ICEA (Institute of Exact and Applied Sciences) in UFOP. For this purpose, a survey of
the was conducted over the network scenerio of the ICEA network and later it was used
the software CORE (Common Open Research Emulator) for testing by using the Dual
Stack, 6over4, and GRE techniques. It was also run an implementation of Tunnel Broker,
offered by Hurricane Electric, outside the environment of emulation. The obtained results
demonstrated, in general, a better performance using IPv4, which presented lower general
averages in relation to IPv6. These results were used to evaluate the metrics of Latency,
Jitter and Packet Loss, allowing a comparative analysis between techniques.
Key-words: IPv4, IPv6, Transition Techniques, CORE, Latency, Packet Loss, Jitter.
Lista de ilustrações
Figura 1 – Representação geográfica das RIRs. . . . . . . . . . . . . . . . . . . . . 28

Figura 2 – Previsão de esgotamento de endereços IPv4 ainda presentes nos RIRs. . 29
Figura 3 – Projeção de Esgotamento blocos IPv4, Fase 3 - Lacnic. . . . . . . . . . 30
Figura 4 – Mapa da Adoção do IPv6. . . . . . . . . . . . . . . . . . . . . . . . . . 31
Figura 5 – Posição do Brasil. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Figura 6 – Cabeçalho IPv4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
Figura 7 – Representação Endereçamento IPv4 . . . . . . . . . . . . . . . . . . . . 36
Figura 8 – Cabeçalho IPv6. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
Figura 9 – Servidor operando em Pilha Dupla. . . . . . . . . . . . . . . . . . . . . 42
Figura 10 – Túnel manual 6over4 entre dois roteadores. . . . . . . . . . . . . . . . 43
Figura 11 – Túnel manual 6over4 entre dois dispositivos. . . . . . . . . . . . . . . . 43
Figura 12 – Pacote com Cabeçalho GRE. . . . . . . . . . . . . . . . . . . . . . . . 44
Figura 13 – Topologia Lógica do Tunnel Broker. . . . . . . . . . . . . . . . . . . . . 45
Figura 14 – Topologia Física do Tunnel Broker. . . . . . . . . . . . . . . . . . . . . 46
Figura 15 – Topologia e funcionamento do túnel 6to4. . . . . . . . . . . . . . . . . 46
Figura 16 – Estabelecimento de Túnel Teredo. . . . . . . . . . . . . . . . . . . . . . 47
Figura 17 – Tradução de endereço IPv4 para IPv6 no Teredo. . . . . . . . . . . . . 47
Figura 18 – Topologia de rede ISATAP. . . . . . . . . . . . . . . . . . . . . . . . . 48
Figura 19 – Exemplo Topologia DS-Lite. . . . . . . . . . . . . . . . . . . . . . . . . 49
Figura 20 – Topologia 4rd. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
Figura 21 – Topologia de rede 6PE. . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
Figura 22 – Túnel automático 6rd. . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
Figura 23 – Topologia da rede com a utilização do dIVI e dIVI-pd. . . . . . . . . . 52
Figura 24 – Diagrama de Sequência do NAT64/DNS64. . . . . . . . . . . . . . . . 53
Figura 25 – Topologia de Rede do NAT64/DNS64. . . . . . . . . . . . . . . . . . . 53
Figura 26 – Diagrama de Sequência do 464XLAT. . . . . . . . . . . . . . . . . . . . 54
Figura 27 – Topologia de Rede do 464XLAT. . . . . . . . . . . . . . . . . . . . . . 54
Figura 28 – Topologia de rede A+P. . . . . . . . . . . . . . . . . . . . . . . . . . . 55
Figura 29 – Topologia de rede NAT444. . . . . . . . . . . . . . . . . . . . . . . . . 56
Figura 30 – Topologia/Experiência. . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
Figura 31 – Resultados trasmissão tráfego streaming. . . . . . . . . . . . . . . . . . 60
Figura 32 – Área de Trabalho, CORE. . . . . . . . . . . . . . . . . . . . . . . . . . 63
Figura 33 – Software iPerf operando. . . . . . . . . . . . . . . . . . . . . . . . . . 64
Figura 34 – Representação do Cenário usado para testes. . . . . . . . . . . . . . . . 67
Figura 35 – Representação Técnica de Pilha Dupla . . . . . . . . . . . . . . . . . . 68
Figura 36 – Comparação de Latência - Computador Cliente-1 - Pilha Dupla . . . . 68
Figura 37 – Comparação de Jitter - Computador Cliente-1 - Pilha Dupla . . . . . . 69
Figura 38 – Comparação de Latência - Computador Cliente-2 - Pilha Dupla . . . . 70
Figura 39 – Comparação de Jitter - Computador Cliente-2 - Pilha Dupla . . . . . . 71
Figura 40 – Representação Técnica 6over4. . . . . . . . . . . . . . . . . . . . . . . 72
Figura 41 – Comparação de Latência - Computador Cliente-1 - 6over4 . . . . . . . 72
Figura 42 – Comparação de Jitter - Computador Cliente-1 - 6over4. . . . . . . . . 73
Figura 43 – Comparação de Latência - Computador Cliente-2 - 6over4. . . . . . . . 74
Figura 44 – Comparação de Jitter - Computador Cliente-2 - 6over4. . . . . . . . . 75
Figura 45 – Comparação de Latência - Computador Cliente-1 - GRE. . . . . . . . . 76
Figura 46 – Comparação de Jitter - Computador Cliente-1 - GRE. . . . . . . . . . 77
Figura 47 – Comparação de Latência - Computador Cliente-2 - GRE . . . . . . . . 78
Figura 48 – Comparação de Jitter - Computador Cliente-2 - GRE . . . . . . . . . . 79
Figura 49 – Tentativa de Ping IPv6 à serviços de Internet. . . . . . . . . . . . . . . 80
Figura 50 – Teste de Ping IPv6 com êxito após configuração de Tunnel Broker . . . 80
Figura 51 – Teste de acesso com IPv6 bem sucedido a um site. . . . . . . . . . . . 81
Figura 52 – Média de Latência IPv4xIPv6 usando Tunnel Broker. . . . . . . . . . . 82
Figura 53 – Média Jitter IPv4xIPv6, usando Tunnel Broker . . . . . . . . . . . . . 83
Figura 54 – Relação de Perda de Pacotes X Pacotes Enviados. . . . . . . . . . . . . 84
Figura 55 – Percental de Perda de Pacotes . . . . . . . . . . . . . . . . . . . . . . . 85
Figura 56 – Tela Inicial. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
Figura 57 – Tela Cadastro. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
Figura 58 – Criação do túnel. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
Figura 59 – Resumo das configurações do túnel. . . . . . . . . . . . . . . . . . . . . 97
Figura 60 – Escolha do SO. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
Figura 61 – Informações de configuração do túnel. . . . . . . . . . . . . . . . . . . 98
Figura 62 – Informações de configuração do túnel no terminal Linux. . . . . . . . . 99
Lista de tabelas
Tabela 1 – Área de abrangência das RIRs. . . . . . . . . . . . . . . . . . . . . . . 28

Tabela 2 – Situação atual dos Blocos IPv4 no Lacnic. . . . . . . . . . . . . . . . . 29
Tabela 3 – Modelo TCP/IP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
Tabela 4 – Opções de campos definidas na versão original do IPv4 . . . . . . . . . 36
Lista de abreviaturas e siglas
AFRINIC African Network Information Centre
AFTR Address Family Transition Router
AP Access Point
APNIC Asia Pacific Network Information Centre
ARIN American Registry for Internet Numbers
ARPANET Advanced Research Projects Agency Network
A+P Address Plus Port
BSD Berkeley Software Distribution
B4 DS-Lite Basic Bridging BroadBand
CERNET2 China Education and Research Network
CIDR Classless Inter-Domain Routing
CGI.br Comitê Gestor da Internet no Brasil
CGN Carrier Grade NAT
CLAT Customer side translator
CORE Common Open Research Emulator
CPE Customer Premises Equipment
DCC Departamento de Ciência da Computação
DECSI Departamento de Computação e Sistemas
DHCP Dynamic Host Configuration Protocol
DHCPv6 Dynamic Host Configuration Protocol version 6
DNS Domain Name System
DS-Lite Dual Stack Lite
FTP File Transfer Protocol

GB GigaBytes
GRE Generic Routing Encapsulation
HTTP Hypertext Transfer Protocol
IANA Internet Assigned Numbers Authority
ICANN Internet Corporation for Assigned Names and Numbers
ICEA Instituto de Ciências Exatas e Aplicadas
IHL Internet Header Length
IoT Internet of Things
IP Internet Protocol
IPv4 Internet Protocol version 4
IPv6 Internet Protocol version 6
ISATAP Intra-Site Automatic Tunnel Addressing Protocol
Lacnic Latin America and Caribbean Network Information Centre
LSN Large Scale NAT
LSPs Label Switch Paths
MB MegaBytes
MBGP Multiprotocol BGP
MOS Mean Opinion Score
ms Milissegundo
NAT Network Address Translation
NAT444 Network address translations at customer’s private network and carrier’s

private network
NAT64 Network Address and Protocol Translation from IPv6 Clients to IPv4
Servers
Nic.br Núcleo de Informação e Coordenação do Ponto BR
NIR National Internet Registry
OSI Open Systems Interconnection

PLAT Provider side translator
QoS Quality of Service
RAM Random Access Memory
RCTS Rede Ciência, Tecnologia e Sociedade
REDUnB Rede de Dados da UnB
RFC Request for Comments
RIPE NCC Réseaux IP Européens Network Coordination Centre
RIR Regional Internet Registry
SMTP Simple Mail Transfer Protocol
TCP Transmission Control Protocol
TTL Time to Live
UBI Universidade da Beira Interior
UDP User Datagram Protocol
UFLA Universidade Federal de Lavras
UFOP Universidade Federal de Ouro Preto
ULA Unique Local Address
ULHT Universidade Lusófona de Humanidades e Tecnologias
UnB Universidade de Brasília
VoIP Voice over Internet Protocol
VPN Virtual Private Network
6in4 IPv6-in-IPv4
6over4 IPv6-over-IPv4
6PE IPv6 Provider Edge router
6rd IPv6 Rapid Deployment
6to4 Connection of IPv6 Domains via IPv4 Clouds

Sumário
1 INTRODUÇÃO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
1.1 Problema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
1.2 Justificativa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
1.3 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
1.4 Estrutura do Trabalho . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
2 REFERENCIAIS TEÓRICOS . . . . . . . . . . . . . . . . . . . . . . 33
2.1 Modelo de Camada TCP/IP . . . . . . . . . . . . . . . . . . . . . . . 33
2.2 IPv4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
2.2.1 Cabeçalho IPv4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
2.2.2 Endereçamento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
2.3 IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
2.3.1 Cabeçalho IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
2.3.2 Cabeçalhos de Extensão . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
2.3.3 Endereçamento IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
2.3.4 Tipos de Endereços definidos em IPv6. . . . . . . . . . . . . . . . . . . . . 41
2.4 Técnicas de Transição e Coexistência . . . . . . . . . . . . . . . . . . 41
2.4.1 Técnica de Pilha Dupla . . . . . . . . . . . . . . . . . . . . . . . . . . 41
2.4.2 Técnicas de Tunelamento . . . . . . . . . . . . . . . . . . . . . . . . . 43
2.4.2.1 Túnel 6over4 – IPv6-over-IPv4 . . . . . . . . . . . . . . . . . . . . . . . . . 43
2.4.2.2 Túneis GRE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
2.4.2.3 Tunnel Brokers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
2.4.2.4 6to4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
2.4.2.5 TEREDO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
2.4.2.6 ISATAP (Intra-Site Automatic Tunnel Addressing Protocol) . . . . . . . . . . . 48
2.4.2.7 Dual Stack Lite (DS-Lite) . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
2.4.2.8 4rd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
2.4.2.9 6PE e 6VPE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
2.4.2.10 6rd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
2.4.3 Técnicas de Tradução . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
2.4.3.1 IVI, dIVI e dIVI-pd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
2.4.3.2 NAT64 e DNS64 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
2.4.3.3 464XLAT (draft-ietf-v6ops-464xlat-01 ) . . . . . . . . . . . . . . . . . . . . . 53
2.4.3.4 A+P(Address Plus Port) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
2.4.3.5 NAT444 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
2.5 Trabalhos Relacionados . . . . . . . . . . . . . . . . . . . . . . . . . . 56
2.5.1 Um Modelo de Migração de Ambiente IPv4 para IPv6 em uma Rede Acadê-
mica Heterogênea. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
2.5.2 Proposta de Implantação do Protocolo IPv6 na Rede da Universidade Federal
de Lavras . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
2.5.3 Estudo da eficiência da comunicação IPv4 versus IPv6 na rede de investigação
e ensino Portuguesa RCTS entre Lisboa e Covilhã . . . . . . . . . . . . . . 59
3 METODOLOGIA . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
3.1 Métricas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
3.2 Softwares . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
3.2.1 CORE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
3.2.2 iPerf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
3.3 Ping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
3.4 Testes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
4 EXPERIMENTOS E RESULTADOS . . . . . . . . . . . . . . . . . . 66
4.1 Cenário de Testes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
4.2 Pilha Dupla . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
4.3 6over4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
4.4 GRE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
4.5 Tunnel Broker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
4.6 Limitações . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
5 CONCLUSÃO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
REFERÊNCIAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
APÊNDICES 93
APÊNDICE A – CONFIGURAÇÕES UTILIZADAS . . . . . . . . . 94

A.1 6over4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
A.2 GRE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
A.3 Tunnel Broker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
APÊNDICE B – MÉDIAS GERAIS E CÁLCULO DE DESVIO PA-

DRÃO . . . . . . . . . . . . . . . . . . . . . . . . . 100
ANEXOS 103
ANEXO A – PLANTA DE IMPLANTAÇÃO DO ICEA . . . . . . . 104

27
1 Introdução
Tecnologias voltadas para a comunicação entre redes de computadores e Internet

surgiram ou foram modificadas visando melhoria em seus processos. Uma das principais
tecnologias que permitiram esse avanço foi o surgimento do IP (Internet Protocol). O
IP (POSTEL, 1981), permite a identificação de cada dispositivo conectado em uma rede
de computadores, assim é possível a comunicação entre eles. Atualmente se encontra
amplamente operacional a versão 4 do protocolo (IPv4). Dados recentes publicados pela
We are Social e Hootsuite (KEMP, 2018) apontam que mais de 4 bilhões de pessoas no
mundo usam a Internet.
Além desse crescente aumento de usuários, avanços na área de pesquisas sobre IoT
(Internet of Things), que prometem interligar os mais diversos tipos de aparelhos à rede
mundial de computadores, denotam o quanto as tecnologias devem ser aperfeiçoadas para
suportarem o futuro que se aproxima, de forma a incluírem novos usuários à rede.
1.1 Problema
O esgotamento dos endereços IPv4 existentes é um fato preocupante. A questão
se agrava devido ao notório atraso da implantação do IPv6. Algumas medidas foram
estudadas e implementadas visando mitigar os problemas causados por este esgotamento,
como por exemplo, o uso do NAT (Network Address Translation) (EGEVANG; FRANCIS,
1994).
A ICANN (Internet Corporation for Assigned Names and Numbers) (ICANN,
2018) é uma entidade sem fins lucrativos, constituída em 1998 responsável pela alocação
de endereçamento IP, através da IANA (Internet Assigned Numbers Authority) (IANA,
2018), autoridade global responsável pela coordenação dos servidores DNS (Domain Name
System) Raiz, endereçamento IP, bem com outros assuntos correlatos ao protocolo. Estão
sob sua tutela direta as RIRs (Regional Internet Registry), que cumprem o papel regional,
como pode ser visto na Figura 1.
28 Capítulo 1. Introdução
Figura 1 – Representação geográfica das RIRs.

Fonte: Imagem extraída do site www.apnic.net.
Ainda existem as NIRs (National Internet Registry), no Brasil por exemplo, cabe
ao NIC.Br - Núcleo de Informação e Coordenação do Ponto BR, subordinado ao LACNIC
(Latin America and Caribbean Network Information Centre), dentre outras funções a de
alocação de endereços IP.
A Tabela 1 descreve a área de abrangência das RIRs
Regional Internet Registry Área de Atuação
ARIN América do Norte e partes do Caribe

Lacnic América Latina e partes do Caribe
AFRINIC África
APNIC Ásia e Pacífico
RIPE NCC Europa, Oriente Médio e Ásia Central
Tabela 1 – Área de abrangência das RIRs.

Fonte: Elaborada pelo autor.
Os blocos IP da versão 4 estão acabando nas RIRs. Segundo (BRITO, 2013b), em

2011 a IANA distribuiu os últimos blocos IPv4 para as RIRs, esgotando assim seu estoque.
A Figura 2 mostra previsão desse esgotamento nas RIRs. Ressaltando que as mesmas
têm feito o trabalho de recuperarem blocos IPv4 que não estão em uso. Atualmente a
AFRINIC (African Network Information Centre) é quem constitui maior número de blocos
ainda disponíveis. As outras RIRs estudam a possibilidade de adquirirem parte desses
blocos.
1.1. Problema 29
Figura 2 – Previsão de esgotamento de endereços IPv4 ainda presentes nos RIRs.

Fonte: Imagem extraída do site http://ipv6.br/ (IPV6.BR, 2018).
Segundo informações divulgadas pelo LACNIC, a região sob sua jurisdição passa no
momento pela fase 3 de esgotamento do IPv4, fase esta que se iniciou em 15 de Fevereiro
de 2017. Isso quer dizer que a regional detém poucos blocos IPv4 que ainda podem ser
distribuídos, agora com muito mais rigor na concessão. Esses blocos advém da última
partilha feita pela IANA, bem como de blocos devolvidos ou recuperados.
A Tabela 2 reproduz informações contidas no site do LACNIC acerca da quantidade
de endereços e operações nesta Fase 3 do processo.
Data de Atualização 28/06/2018

Endereços IPv4 Totais 5.061.120
Endereços IPv4 devolvidos/revogados nesta fase: 941.568
Endereços IPv4 alocados nesta fase: 1.920.768
Endereços IPv4 disponíveis nesta fase: 3.140.352
Tabela 2 – Situação atual dos Blocos IPv4 no Lacnic.
Fonte: Dados extraídos de (LACNIC, 2018).
Dados estatísticos do Lacnic (LACNIC, 2018) apontam uma previsão de quando

podem se esgotar os endereços remanecentes em seu centro, com data prevista para 11/2019,
como pode ser visualizado na Figura 3.
Figura 3 – Projeção de Esgotamento blocos IPv4, Fase 3 - Lacnic.

Fonte: Imagem extraída do site http://www.lacnic.net/ (LACNIC, 2018).
1.2 Justificativa
Com o surgimento do IPv6, surgiu também um novo questionamento: Como

implantar essa nova versão garantindo que haja os menores danos possíveis, ou seja, iniciar
um processo complexo de migração, sem deixar a rede atual inoperante e garantir que
todos os serviços existentes continuem operacionais pós transição? Diversas técnicas foram
criadas com este fim, classificadas em 3 categorias: Pilha Dupla, Tunelamento e Tradução.
Pilha Dupla consiste que todos os dispositivos presentes na rede estejam configurados com
as duas versões do protocolo (IPv4/IPv6) e foi indicada como técnica preferida para que
houvesse um processo gradual de mudança, sendo amplamente indicado seu uso sempre
que possível. Entender as características do IPv6, das técnicas existentes à necessidade e
importância desse momento de transição tornou-se primordial para o sucesso desse projeto.
O processo tem sido complexo e está de forma geral atrasado, já que o plano inicial
era implantar o IPv6 em toda Internet antes do esgotamento do IPv4 (SANTOS et al.,
2012). Mas é de primordial importância para o crescimento da Internet, principalmente
com os recentes estudos e avanços sobre IoT.
1.2. Justificativa 31
A Figura 4 mostra como está a adoção do IPv6 no mundo, segundo dados estatís-
ticos levantados pela APNIC. Quanto mais clara a cor representada no mapa maior é a
porcentagem de uso.
Figura 4 – Mapa da Adoção do IPv6.

Fonte: Imagem extraída do site https://www.apnic.net/.
O Brasil figura entre os 10 primeiros países com maior utilização do IPv6 segundo
este levantamento, conforme pode ser visto na Figura 5.
Figura 5 – Posição do Brasil.

Fonte: Imagem extraída do site https://www.apnic.net/.
1.3 Objetivos
Neste contexto, objetiva-se com este trabalho realizar um estudo geral de algumas
das principais características do IPv6, bem como de algumas técnicas de transição e
coexistência entre redes IPv4/IPv6. Permitindo um embasamento teórico sobre as áreas es-
tudadas, possibilitando entender como o novo protocolo pode contribuir para o crescimento
e evolução da Internet.
Como forma de exemplificar o funcionamento das técnicas de transição e coexis-
tência, pretende-se realizar um estudo de caso com quatro das técnicas estudadas: Pilha
Dupla, 6over4, GRE (Generic Routing Encapsulation) e Tunnel Broker, utilizando para
isso uma representação de parte da estrutura de rede do ICEA, que será emulada por
meio do CORE. Buscando obter dados fora do ambiente emulado, a experimentação com
Tunnel Broker será realizada utilizando um serviço de túnel IPv6 fornecido pela Hurricane
Eletric (ELECTRIC, 2018).
1.4 Estrutura do Trabalho

Demais textos deste trabalho estão ordenados da seguinte forma:
• Capítulo 2: relata os referenciais teóricos para realização do trabalho, como por

exemplo, IPv4, IPv6, técnicas de transição e coexistência e trabalhos relacionados.
• Capítulo 3: descreve a metodologia seguida para elaboração dos testes, Softwares

usados, e métricas estudadas.
• Capítulo 4: estão contidos os experimentos e resultados obtidos em cada técnica e

limitações encontradas.
• Capítulo 5: descreve a conclusão e trabalhos futuros.

33
2 Referenciais Teóricos
2.1 Modelo de Camada TCP/IP

Segundo (WETHERALL; TANENBAUM, 2011), o modelo TCP/IP (Transfer
Control Protocol/Internet Protocol) teve seu surgimento ainda na era da ARPANET
(Advanced Research Projects Agency Network), em meio à visível preocupação do Comando
de Defesa dos Estados Unidos em garantir o funcionamento de comunicação de sua rede.
Originalmente é composto por 4 camadas e seu nome advém de dois protocolos que fazem
parte do modelo: TCP e IP. Este modelo é apresentado na Tabela 3.
O modelo TCP/IP composto por quatro camadas:
4 Aplicação
3 Transporte
2 Internet
1 Enlace
Tabela 3 – Modelo TCP/IP.
Fonte: Elaborada pelo autor
Camada de Aplicação
Nesta camada estão presentes os protocolos de alto nível, como por exemplo: FTP
(File Transfer Protocol), SMTP (Simple Mail Transfer Protocol) e HTTP (HyperText
Transfer Protocol). Essa camada realiza a ligação com as aplicações dos usuários.
Camada de Transporte
Abaixo da camada de Aplicação encontramos a camada de Transporte, e esta
tem por preceito a comunicação origem/destino na rede TCP/IP. O TCP e o UDP
(User Datagram Protocol) compõem esta camada. O TCP ao receber uma mensagem a
subdivide em pacotes menores e os encaminha. O protocolo oferece confiabilidade em
conexão, sequenciamento, conferência e retransmissão dos pacotes. O UDP não é orientado
à conexão, e portanto não garante confiabilidade. Seu uso é mais empregado em aplicações
onde a rapidez nas entregas dos pacotes é mais essencial do que a precisão, (WETHERALL;
TANENBAUM, 2011)
Camada Internet
Aqui ocorrem os envios dos pacotes recebidos pela camada de transporte da rede de
origem para um destino, mesmo em redes diferentes. Essa camada não pretende garantir
34 Capítulo 2. Referenciais Teóricos
que os pacotes sejam entregues na ordem em que são enviados, mas que eles cheguem ao
destino independente dos caminhos percorridos. Aqui está presente a atuação do IP.
Camada de Enlace
A camada de rede do modelo TCP/IP, engloba as funções da camada Física e a de
Enlace em relação ao modelo OSI (Open Systems Interconnection). Por esse motivo, ela
apresenta funções como: permitir conexões de cabeamento, bem como conversões de sinais
elétricos. Também controla o fluxo, evitando a sobrecarga e provendo controle de erros ao
enviar os arquivos recebidos.
Alguns autores incluíndo (WETHERALL; TANENBAUM, 2011), adotam o uso do
modelo com 5 camadas, com a camada Física separada da Enlace.
2.2 IPv4
A versão 4 do IP é datada de Setembro de 1981 e suas especificações referenciadas
na RFC791 (POSTEL, 1981). Sua utilização tem sido ainda predominante na Internet.
Segundo (COMER, 2015), desde sua criação em meados da década de 70, o escopo do seu
projeto não passou por muitas modificações, mostrando-se flexível e robusto. A Figura 6
mostra o cabeçalho IPv4.
2.2.1 Cabeçalho IPv4
Figura 6 – Cabeçalho IPv4

Fonte: Elaborado pelo autor com base em (POSTEL, 1981).
Com base em (POSTEL, 1981) e (BARRETO, 2015) obtivemos as informações

sobre os campos do Cabeçalho IPv4.
2.2. IPv4 35
Versão - 4 bits: Indica a versão do Protocolo.

Tamanho do Cabeçalho - 4 bits: O tamanho do cabeçalho é variável. Este
campo marca o início dos dados. O valor mínimo é 5.
Tipo de Serviço - 8 bits: Este campo e destinado para indicar parâmetros de
qualidade de serviço desejada aos datagramas. Como por exemplo, fornecer indicações
baixo atraso, alta confiabilidade e alto rendimento.
Tamanho Total - 16 bits: Indica o tamanho total do datagrama, máximo de
65.535 bytes.
Identificação - 16 bits: Responsável pela identificação do datagrama.
Flags - 3 bits: Sinais de Controle. Bit 0: Bit reservado, seu valor deve ser 0. Este
Bit já foi indicado para ser utilizado como Bit para detecção de tráfego malicioso.
• Bit 1 [DF] (Don’t Fragment) – Não Fragmentar: Um indicativo para que roteadores
não consigam fragmentar os datagramas.
• Bit 2 [MF] (More Fragments) – Mais Fragmentos: Com este campo é possível verificar
quando todos os fragmentos do datagrama chegaram ao destino. Isso porque apenas
o último fragmento não contém este conjunto de bits.
Deslocamento de Fragmento - 13 bits: Este campo fornece um valor sequencial

a cada parte do datagrama. Isso permite que ao final os fragmentos sejam montados em
sua ordem.
Tempo de Vida - 8 bits: Um campo com função contador, que é decrementado
em uma unidade a cada salto. Quando chega a 0 (zero), o pacote é então descartado.
Protocolo - 8 bits: Mostra o protocolo responsável pela montagem e envio dos
pacotes.
Soma de verificação do Cabeçalho - 16 bits: Usado para controle e verificação
do datagrama. A cada Hop na rede este campo deve ser recontado, isso porque o campo
Tempo de Vida é alterado.
Endereço de Origem - 32 bits: Endereço de Origem.
Endereço de Destino - 32 bits: Endereço de Destino.
Opções - Tamanho Variável: Este campo teve seu propósito pensado para
utilização futura, ou seja, permitiria a outras versões do protocolo acrescentar dados
que não compunham a primeira versão. Em seu projeto original haviam algumas opções
definidas, como mostra a Tabela 4 à seguir.
Opção Descrição
Security Nível de segurança do datagrama.
Strict Source Routing Caminho completo desde a origem ao destino.
Loose Source Routing Contém uma lista com todos os roteadores que
obrigatoriamente o pacote deve passar, mas não
proíbe que o pacote passe por outros roteadores.
Record Route Este campo mostra que cada roteador deverá regis-
trar seu id no campo opções.
Timestamp Cada roteador deve registrar além do seu ID, tam-
bém seu registro de tempo.
Tabela 4 – Opções de campos definidas na versão original do IPv4
Fonte: Elaborado pelo autor.
2.2.2 Endereçamento
No IPv4 o tamanho de endereçamento igual a 32 bits, resultando em uma geração
de 4.294.967.296 números IP possíveis. Seu campo é representado por 4 blocos de 8 bits
cada e pode ser escrito por números decimais (para maior legibilidade) que vão de 0 a 255
sendo cada bloco separado por um ponto (.), como pode ser visto na Figura 7.
Figura 7 – Representação Endereçamento IPv4

2.3 IPv6
Atualmente referenciado na RFC8200 (HINDEN, 2017), o IPv6 passou por altera-
ções se comparado à versão anterior, como por exemplo, número de campos no cabeçalho
e na capacidade de geração de endereços.
O campos receberam um valor fixado, de tamanho 40 bytes e foram reduzidos a
apenas 8. Mudanças que garantiram ao protocolo maior simplicidade e seu cabeçalho
2.3. IPv6 37
ficou apenas duas vezes maior. Pelo fato de possuir com valores fixados houve a remoção
do campo Tamanho do Cabeçalho (IHL). Os campos Identificação, Deslocamento de
Fragmento, Flags, Opções e Complementos, também deixaram de existir na versão IPv6 e
suas informações passaram a constar nos cabeçalhos de extensão.
O campo Limite de Encaminhamento substitui o campo Tempo de Vida. O campo
Tipo de Serviço foi substituído pelos campos Classe de Tráfego e Identificador de Fluxo,
sendo este último responsável por implementação e suporte a Qualidade de Serviço (QoS).
Campo Tamanho dos Dados substitui o antigo campo Tamanho Total. Os campos
Versão, Endereço de Origem e Endereço de Destino, sofreram alteração apenas em seus
tamanhos. A Figura 8 mostra o cabeçalho IPv6.
2.3.1 Cabeçalho IPv6
Figura 8 – Cabeçalho IPv6.

Fonte: Reprodução baseada no material do Curso IPv6 Básico. (SANTOS et al., 2012)
Com base em (HINDEN, 2017), (BARRETO, 2015) e (SANTOS et al., 2012),

obtemos as características dos campos presentes no Cabeçalho IPv6.
Versão - 4 bits: Responsável pela identificação da versão de protocolo. Esse campo
possui valor 6.
Classe de Tráfego - 8 bits: Responsável por indicar a classe ou prioridade de
um pacote IPv6. Continua implementando as mesmas funcionalidades do campo Tipo de
Serviço do antecessor IPv4.
Identificador de Fluxo - 20 bits: Identifica os pacotes contidos em um mesmo

fluxo de comunicação, presentes na camada de rede. Isso garante que um roteador possa
discernir qual o fluxo de cada um dos pacotes, sem a necessidade de verificação da aplicação.
Tamando de Dados - 16 bits: Mostra o tamanho dos dados que são encami-
nhados no cabeçalho do IPv6, em Bytes. Cabeçalhos de Extensão também podem ser
combinados neste campo.
Próximo Cabeçalho - 8 bits: Mostra qual o tipo de cabeçalho de extensão
seguinte. Este campo substitui o campo Protocolo (IPv4).
Limite de Encaminhamento - 8 bits: Mostra a quantidade máxima de rote-
adores que um pacote deve percorrer antes de seu descarte. Este campo tem seu valor
decrementado a cada salto. Diferencia-se do campo TTL do IPv4 pelo fato deste último
indicar essa marcação em segundos.
Endereço de Origem - 128 bits: Endereço de Origem dos Pacotes.
Endereço de Destino - 128 bits: Endereço de Destino dos Pacotes.
2.3.2 Cabeçalhos de Extensão

No IPv6 opções podem ser resolvidas utilizando Cabeçalhos de Extensão. Esse
tipo de cabeçalho está inserido entre os cabeçalho base e o da camada superior. Possuem
tamanhos variados e não há limitação de quantidade. O campo Próximo Cabeçalho contido
no IPv6, aponta para o primeiro cabeçalho de extensão e cada um dos Cabeçalhos de
Extensão inseridos deve conter um campo Próximo Cabeçalho, constituindo assim uma
ramificação, Cadeia de Cabeçalhos (SANTOS et al., 2012).
Isso permitiu uma operacionalidade mais eficiente e maior velocidade ao IPv6,
isso porque, somente o Hop-by-Hop é tratado em cada um dos roteadores, deixando o
tratamento dos outros à cargo do nó destino que esta indicado no cabeçalho base (SANTOS
et al., 2012).
Seis cabeçalhos são definidos pelo IPv6:
Hop-by-Hop Options: Registrado com valor 0 no campo Próximo Cabeçalho
e colocado posteriormente ao cabeçalho IPv6. Contém diversas informações que serão
processadas por todos os demais nós presentes no caminho entre a origem e destino dos
pacotes.
Destination Options: Possui valor 60 no campo Próximo Cabeçalho, possui
informações que serão processadas pelo nó destino que está contido no campo Endereço
de Destino.
Routing: Gravado com valor 43 no campo Próximo Cabeçalho, foi criado visando
2.3. IPv6 39
identificar os nós intermediários por onde passariam os pacotes até o destino. Por motivos
relacionados à segurança, essa particularidade foi descontinuada e seu registro feito na
RFC5095 (ABLEY; SAVOLA; NEVILLE-NEIL, 2007). Recentemente, um Type 2 foi
especificado e é utilizado como suporte à mobilidade do IPv6.
Fragmentation: Registrado com valor 44 no campo Próximo Cabeçalho, possui
informações de fragmentos dos pacotes IPv6.
Authetication Header: Possui valor 51 no campo Próximo Cabeçalho, garante
autenticação e integridade aos pacotes IPv6.
Encapsulating Security Payload: Possui valor 52 no campo Próximo Cabeça-
lho, visa dar integridade e confidencialidade aos pacotes IPv6. Esses dois últimos cabeçalhos
são usados pelo IPSec.
Aspectos Importantes
É uma boa prática o emprego dos Cabeçalhos de Extensão na ordem a seguir:
• Hop-by-Hop Options;
• Routing;
• Fragmentation;
• Authentication Header;
• Encapsulating Security Payload;
• Destination Options.
Isso permite que os hosts existentes no caminho necessitem explorar a cadeia de

cabeçalhos por inteiro. Cabeçalhos de relevância para todos os hosts são posicionados à
frente, já os que tm sua importância apenas ao host destinatário, têm seu posicionamento
ao final. Assim, ao encontrar um cabeçalho endereçado a um host destinatário específico
que não ele, o host que está realizando a análise pare seu processamento, elevando o
desempenho no processamento dos pacotes.
Pacotes com destino Multicast terão seus cabeçalhos analisados por todos o hosts
deste grupo.
2.3.3 Endereçamento IPv6

A versão 6 do Protocolo IP apresenta um espaço de endereçamento fixado em 128
bits, o que proporciona a geração de
340.282.366.920.938.463.463.374.607.431.768.211.456, (340 Undecilhões) de ende-

reços possíveis. Quantidade bem superior em relação ao antecessor que gerava uma
combinação de 4.294.967.296 de endereços.
Um endereço IP gerado em IPv6 é subdividido em oito grupos de contendo 16
bits (Duplo-Octetos ou Hexadecatetos), que são escritos em formato Hexadecimal (0-F)
maiúsculo ou minúsculos, sendo que cada grupo deve ser separado por um sinal de (:).
Para mais legibilidade há algumas particularidades que podem ser adotadas no
momento de escrever um endereço IPv6:
• Omissão de 0 à esquerda em cada grupo de 16 bits,
• Separação por (::) em cadeias longas de 0.
Este último tipo de abreviação deve ser considerado apenas uma única vez em um endereço,
para não gerar ambiguidade.
Ex: 2001:0DB8:AD1F:25E2:CADE:CAFE:F0CA:84C1
2001:0DB8:0000:0000:130F:0000:0000:140B
2001:db8:0:0:130f::140b (Endereço acima omitindo-se os zeros e usando a nota-
ção (::).)
Ex: Gerando ambiguidade:
Válido: 2001:0DB8:0000:0000:130F:0000:0000:140B
Usando Notação (::):
Ambiguidade: 2001:DB8::130F::140B
Não seria possível determinar se o endereço corresponderia por exemplo à:
2001:DB8:0:0:130F:0:0:140B,
2001:DB8:0:0:0:130F:0:140B,
2001:DB8:0:130F:0:0:0:140B.
O IPv6 faz a representação de prefixos de rede utilizando o formato estabelecido

na notação CIDR (Classless Inter-Domain Routing), ou seja, endereço-IPv6/Tamanho do
Prefixo.
Ex: Prefixo 2001:db8:3003:2::/64
O número contido após o sinal de ‘/’, refere-se ao valor da quantidade de Bits que
representam a rede.
2.4. Técnicas de Transição e Coexistência 41
2.3.4 Tipos de Endereços definidos em IPv6.

Unicast: Identifica um único host na rede. Esta categoria de endereço subdivide-se
em:
• Global Unicast: Este tipo de endereço é aquele que é roteável em uma rede IPv6.
Está faixa de endereços está estabelecida hoje dentro do limite:
2000:: a 3fff:ffff:ffff:ffff:ffff:ffff:ffff:ffff, nos dando uma taxa de 13% do total de
endereços que podem ser gerados no IPv6.
• Link Local: Registrado sob o prefixo: FE80::/64, este tipo de link é exclusivamente
usado em uma rede local.
• Unique Local Address (ULA): Usado unicamente em operações locais, em um

mesmo enlace ou conjunto de enlaces.
Anycast: São utilizados para identificar um grupo de hosts em uma rede. Não há
uma faixa de endereços destinados a essa categoria, podendo ser usado qualquer endereço
Unicast. Podem ser usados quando se necessita realizar balanceamento de carga ou mesmo
redundância de dados. Por exemplo, o uso em servidores DNS, caso um servidor desses
falhe em uma determinada região, haverá uma outra máquina do grupo com o mesmo
número IP que fornecerá a solução.
Multicast: Em IPv6, não há a presença de Endereços Broadcast, onde uma
mensagem enviada para essa faixa era vista por todos o nós desta rede. Endereços Multicast
tem seu funcionamento parecido, identificado um grupo de hosts que em uma determinada
interface, e um ou mais hosts podem estar presentes em outro grupo Multicast. Quando se
envia uma mensagem a esta faixa de endereços, todos os hosts que estão contidos nesta
faixa receberam a mensagem. Estão na faixa FF00::/8 e são de extrema importância em
uma rede IPv6. Através deles por exemplo, o protocolo consegue desempenhar a descoberta
de vizinhança.
2.4 Técnicas de Transição e Coexistência

2.4.1 Técnica de Pilha Dupla
A técnica de Pilha Dupla foi a implementação escolhida para ser utilizada no
processo de transição, logo quando os endereços IPv4 davam sinais de que não seriam
suficientes para o rápido crescimento da Internet. De acordo com (BRITO, 2013b), essa
técnica visa permitir a interoperabilidade de dispositivos usando IPv4 e IPv6 simulta-
neamente, e com sua adoção o que se esperava era um processo de transição gradual e
limpo.
Dessa forma, todos os dispositivos interligados na rede possuem as duas versões dos
protocolos nas duas pontas, garantindo a possibilidade de envio e recebimento de ambos
pacotes.
Quando implementado dessa forma um host possui artifícios que realizam confi-
gurações IPv4 (ex:. DHCP), e mecanismos próprios para configurações IPv6 (DHCPv6,
configurar manualmente), se comportando da seguinte maneira:
• O host terá o comportamento de uma das duas versões do protocolo de acordo com
qual tipo de implementação de IP o seu interlocutor estiver utilizando.
• Ex: O host A se comportará como um host IPv4, se o host B, for um host IPv4. O
mesmo vale para o IPv6.
Alguns serviços devem ser configurados de forma específica para cada versão na
Pilha Dupla, como por exemplo, firewalls e Protocolos de Roteamento.
Contudo, apesar de ser umas das formas mais aceitas para a coexistência das redes,
implementar uma Pilha Dupla significa manter duplo gerenciamento, duas tabelas de
roteamento, resultando em elevar a complexidade da rede e muitas vezes em queda de
desempenho (FLORENTINO, 2012). Segundo (SANTOS et al., 2012), há situações onde
a implementação dessa técnica não é possível, por exemplo:
• Inexistência de IP’s da versão 4 e há necessidadede inserir novos usuários usando

IPv4 e IPv6,
• Equipamentos que não ofereçam suporte ao IPv6.
A Figura 9 demonstra o funcionamento da técnica de Pilha Dupla
Figura 9 – Servidor operando em Pilha Dupla.

Fonte:(BRITO, 2013b)
2.4.2 Técnicas de Tunelamento

Segundo (BRITO, 2013b), tunelamento permite que um conteúdo baseado em uma
tecnologia possa trafegar em um canal constituído em outra tecnologia. É uma modalidade
muito utilizada nesse período de transição, permitindo que redes puramente IPv6 possam
se comunicar através de redes IPv4, ou vice-versa (SANTOS et al., 2012). Existem inúmeras
implementações de túneis, que podem ser configurados de forma manual ou automática.
2.4.2.1 Túnel 6over4 – IPv6-over-IPv4
O 6over4 documentado na RFC4213 (GILLIGAN; NORDMARK, 2005) utiliza a

técnica 6in4 também presente na RFC4213. Para encapsular seus pacotes, usa um túnel
configurado manualmente entre dois hosts puramente IPv4. Normalmente empregado
quando equipamentos ou mesmo a rede só oferecem suporte ao IPv4 ou quando é preciso
interligar dois hosts IPv6 por meio de uma rede IPv4. As Figuras 10 e 11 mostram
configurações do 6over4 entre roteadores e dispositivos respectivamente.
Figura 10 – Túnel manual 6over4 entre dois roteadores.

Fonte:(NIC.BR, 2012)
Figura 11 – Túnel manual 6over4 entre dois dispositivos.

2.4.2.2 Túneis GRE
O túnel GRE referenciado na RFC2784 (HANKS et al., 2000), é um tipo de

implementação de tunelamento estático. Permite realizar o transporte de inúmeros tipos
de protocolos, como IPv4, IPv6, etc, e pode ser transportado em vários tipos de protocolos.
Grande maioria dos sistemas operacionais e roteadores suportam GRE.
Para realizar um encapsulamento de um protocolo IPv6 para IPv4 é necessário
apenas acrescentar o cabeçalho GRE depois o cabeçalho IPv4. Enumerar o campo Protocolo
no cabeçalho IPv6 para 47 (2F), indicando que o IPv4 carrega GRE, e realizar o envio.
No host destino ocorre o desencapsulamento do GRE e IPv4 e o pacote original é por fim
direcionado (SANTOS et al., 2012).
A Figura 12 demonstra a montagem de um pacote com cabeçalho GRE.
Figura 12 – Pacote com Cabeçalho GRE.

2.4.2.3 Tunnel Brokers
Definida na RFC3053 (GUARDINI; DURAND; LENTO, 2001), essa modalidade

visa fornecer acesso IPv6 por meio de um túnel provido geralmente por provedor de acesso
e permite desde dispositivos individuais até mesmo que redes inteiras IPv4 consigam se
comunicar com uma rede IPv6.
De acordo com (SANTOS et al., 2012), é necessário que o usuário faça um cadastro
em um dos provedores de túnel, que posteriormente realiza a configuração em sua ponta.
Esse provedor envia as instruções e/ou um programa cliente para o acesso. O usuário
realiza as configurações no lado cliente.
Esse tipo de serviço é indicado para aqueles que desejam implantar em modo teste
a adoção do IPv6, mas que ainda não dispõem de blocos fornecidos por suas operadoras
de redes ou suporte ao mesmo.
Acessos por meio de Tunnel Broker podem ser lento, já que todo tráfego é realizado
por meio de uma VPN segundo (FLORENTINO, 2012).
Alguns provedores de Tunnel Broker:
• http://tunnelbroker.net/
• http://sixxs.net/main/
As Figuras 13 e 14 mostram as topologias lógica e físicas de um Tunnel Broker,

respectivamente.
Figura 13 – Topologia Lógica do Tunnel Broker.

Figura 14 – Topologia Física do Tunnel Broker.

Fonte:(SANTOS et al., 2012)
2.4.2.4 6to4
Prevista na RFC3056 (CARPENTER; MOORE, 2001), essa técnica utiliza a im-

plementação de túneis 6in4 configurados automaticamente, auxiliados por inúmeros relays
que implementam pilha dupla distribuídos na Internet permitido redes IPv4 acessarem
redes IPv6 (SANTOS et al., 2012).
O 6to4 apresentou diversos problemas como lentidão, e aqueles relacionados à
segurança (BRITO, 2013b). Não recomenda-se uso desta técnica. A Figura 15 demonstra
o funcionamento e topologia de túnel 6to4.
Figura 15 – Topologia e funcionamento do túnel 6to4.

2.4.2.5 TEREDO
Criado pela Microsoft, estabelece conexões IPv6 por meio de túneis IPv4, en-
capsulados os pacotes com o Protocolo UDP. Técnica está regulamentada na RFC4380
(HUITEMA, 2006)
O servidor Teredo se comunica utilizando a porta UDP 3544 e através dele que são
feitas as conexões por meio de NAT (SANTOS et al., 2012). O relay Teredo é responsável
pelo interfaceamento entre hosts cliente e destino.
Há críticas a essa técnica que estão relacionados aos fatores segurança e desempenho,
como por exemplo: um conteúdo que está encapsulado e que deveria ser bloqueado em
uma rede IPv4, consegue atingir seu destinatário (NIC.BR, 2012).
Figura 16 – Estabelecimento de Túnel Teredo.

Figura 17 – Tradução de endereço IPv4 para IPv6 no Teredo.

De acordo com (BRITO, 2013b) pelo fato de usar NAT, torna-se possível a existência
de riscos à segurança, principalmente em um ambiente organizacional, já que conteúdos
não autorizados presentes nas redes poderiam obter acesso através de túnel automático
em hosts que estejam operando sistema operacional Windows.
2.4.2.6 ISATAP (Intra-Site Automatic Tunnel Addressing Protocol)
Essa técnica de tunelamento prevista na RFC5214 (TEMPLIN et al., 2005), é

empregada permitindo construção de túneis internos na rede (BRITO, 2013b). Segundo
(SANTOS et al., 2012), por não haver uma implementação de serviço público dessa técnica,
ela é usada nas organizações. Principalmente quando há IPv6 na borda da rede mas não
possua suporte na infraestrutura interna.
Ainda segundo (SANTOS et al., 2012), ISATAP tem por premissa interligar diversos
dispositivos aos roteadores.
Figura 18 – Topologia de rede ISATAP.

2.4.2.7 Dual Stack Lite (DS-Lite)
Referenciada na RFC6333 (DURAND et al., 2011), essa técnica tem seu uso
indicado caso um provedor já possua e ofereça aos usuários a rede IPv6 nativa. Nesse
cenário a quantidade de IPv4 já não está mais disponível e a quantidade de usuários ainda
é uma demanda em crescimento (SANTOS et al., 2012).
É criado um túnel que envia pacotes IPv4 sobre uma rede IPv6. Ao desejar acesso
a uma rede que ofereça conteúdo IPv6 o cliente B4 (DS-Lite Basic Bridging BroadBan)
estabelece um túnel e envia o pacote pela rede. No destino por meio de um equipamento
AFTR (Address Family Transition Router) o pacote é submetido a um processo CGN
(Carrier Grade NAT ) e então é entregue ao destinatário.
A Figura 19 mostra a topologia do DS-Lite.
Figura 19 – Exemplo Topologia DS-Lite.

Ainda segundo (DURAND et al., 2011), o uso dessa técnica permite:
• Desacoplar implantações de IPv6 na rede do provedor, quando já tem a implantação

do mesmo na Internet, aplicações e dispositivos do cliente;
• Gerenciamento simplificado às redes de acesso de provedores de serviços, devido ao

espaço de endereçamento IPv6;
• Flexibilidade para adaptação à mudança de carga de tráfego.
2.4.2.8 4rd
Prevista na RFC7600 (CHEN et al., 2015), essa técnica possui um comportamento

equivalente ao DS-Lite e é baseado no 6rd. Segundo (SANTOS et al., 2012), utiliza o
compartilhamento dos endereços IP com restrições de portas e tem características que
direcionam seu emprego a provedores de acesso.
Essa técnica também é destinada ao uso em redes puramente IPv6, pois consegue
manter uma conexão fim-a-fim. Utiliza stateless, mas quando se precisa usar o statefull
essa técnica emprega no lado do usuário o compartilhamento de endereços por meio de
NAT e restrições de porta.
A Figura 20 ilustra a topologia do 4rd.
Figura 20 – Topologia 4rd.

2.4.2.9 6PE e 6VPE
Por meio do uso de core MPLS IPv4, utilizando LSPs (Label switch Paths), essas
técnicas conseguem realizar as comunicações.
Para implementação dessas técnicas usam-se MBGP(Multiprotocol BGP) em cima
dos pacotes IPv4 sendo necessário que os roteadores de bordas implementem Pilha Dupla.
Em 6PE prevista na RFC7498 (FAUCHEUR et al., 2007) há somente uma tabela
de roteamento, ao contrário do 6VPE (CARUGI; CLERCQ; OOMS, 2006). A Figura 21
mostra a topologia desta técnica.
Figura 21 – Topologia de rede 6PE.

2.4.2.10 6rd
Segundo (SANTOS et al., 2012), emprega-se 6rd (DESPRES, 2010) para garantir
que usuários consigam acesso a redes IPv6 mesmo quando a rede ofertada é puramente
IPv4.
O software do CPE 6rd passou por uma modificação que permitiu o uso de 6rd.
O 6rd Replay realiza o encapsulamento e desencapsulamento dos pacotes. A Figura 22
mostra uma demonstração do 6rd.
Figura 22 – Túnel automático 6rd.

Fonte:(ACOSTA et al., 2014)
De acordo com (BRITO, 2013b), 6rd se diferencia de 6to4 pela inexistência de

relays públicos na Internet, assim, trafegam pelos gateways da operadora todo conteúdo
que é destinado aos clientes.
2.4.3 Técnicas de Tradução

Técnicas de tradução utilizam o conceito de NAT para realização da tradução
de pacotes. Segundo (CARVALHO, 2015), com essa técnica, equipamentos usando IPv6
consiguem se comunicar com outros que usam IPv4 por meio da conversão de pacotes.
Apesar de ser uma solução paliativa, devido a existência de muitos problemas
ocasionados pelo seu uso, é também uma categoria ainda muito utilizada, no cenário de
esgotamento do IPv4 vivenciado.
2.4.3.1 IVI, dIVI e dIVI-pd
Aqui, as metodologias dIVI (draft-xli-behave-divi-04 ) e dIVI-pd (draft-xli-behave-

divi-pd-01 ) são extensões da RFC 6052 (BAO et al., 2010), utilizando técnicas stateless
de pilha dupla em tradução de pacotes. Tratam-se de extensões IVI (BAO et al., 2011),
uma técnica desenvolvida pelo CERNET2, rede puramente IPv6 chinesa (SANTOS et al.,
2012).
No dIVI-pd é possível utilizar um prefixo IPv6, e somente a atribuição de um único
endereço IPv4. A Figura 23 demonstra a topologia dessa técnica.
Figura 23 – Topologia da rede com a utilização do dIVI e dIVI-pd.

2.4.3.2 NAT64 e DNS64
Com especificações previstas em RFC6146 (BAGNULO; MATTHEWS; BEIJNUM,

2011) e 6147 (BAGNULO et al., 2011), essas técnicas também são usadas quando se
necessita permitir o acesso de nós IPv6 em redes IPv4.
De acordo com (SANTOS et al., 2012), a NAT64 age simultaneamente com o
DNS64 e realiza a tradução de Pacotes IPv6 para IPv4. É aconselhado que se utilize blocos
de endereços na faixa 64:ff9b::/96, que é designada justamente para o uso em mapeamento
IPv4/IPv6.
Usa-se o processo IVI para conversão IPv6/IPv4. A Figura 24 mostra o diagrama
de sequência desta técnica.
Figura 24 – Diagrama de Sequência do NAT64/DNS64.

A Figura 25 mostra a topologia de rede NAT64/DNS64.
Figura 25 – Topologia de Rede do NAT64/DNS64.

Segundo (FLORENTINO, 2012), a incompatibilidade de alguns aplicativos com a

implementação de NAT utilizada torna-se um inconveniente ao uso dessa abordagem.
2.4.3.3 464XLAT (draft-ietf-v6ops-464xlat-01 )
464XLAT (MAWATARI; KAWASHIMA; BYRNE, 2013), utiliza uma técnica

stateful e stateless na tradução de pacotes IPv4/IPv6 e é destinada a permitir o comparti-
lhamento IPv4 a usuários IPv6.

De acordo como (SANTOS et al., 2012), o CLAT (customer side translator) (BAO
et al., 2016) realiza uma tradução 1:1 é stateless (Um endereço IPv6 tem apenas um IPv6
análogo), já o PLAT (Provider Side Translator) é statefull e realiza uma tradução 1:N
(inúmeros IPv6 globais tem sua representação em um único IPv4), que conversa com a
rede IPv4.
As Figuras 26 e 27 à seguir mostram o diagrama de sequência e topologia do
464XLAT respectivamente.
Figura 26 – Diagrama de Sequência do 464XLAT.

Figura 27 – Topologia de Rede do 464XLAT.

2.4.3.4 A+P(Address Plus Port)
Referenciada na RFC6346 (CITTADINI et al., 2011), utiliza-se A+P para garantir

que aos usuários acesso IPv4 neste momento de transição. Por meio de NAT essa técnica
consegue compartilhar um mesmo endereço IP com vários usuários na rede simultaneamente
(SANTOS et al., 2012).
A Figura 28 representa a topologia A+P.
Figura 28 – Topologia de rede A+P.

Fonte: (SANTOS et al., 2012)
2.4.3.5 NAT444
Também conhecida como LSN (Large Scale NAT ), o NAT444 (KUARSINGH et al.,
2013) permite que blocos de IP’s sejam usados amplamente por meio de compartilhamento
simultâneo. Isso poderia ser um grande aliado na fase de transição e prolongaria a vida
útil dos endereços IPv4 (SANTOS et al., 2012), mas trata-se de um artifício que demanda
equipamentos de alto custo, além de fatores técnicos como provável colisões de endereços.
Essa visão é também compartilhada por (CORDEIRO, 2014), em seu trabalho intitulado
Comparação de técnicas de transição do IPv4 para o IPv6 de 2014.
A Figura 29 demonstra a tolopogia do NAT444.
Figura 29 – Topologia de rede NAT444.

Fonte: (SANTOS et al., 2012)
2.5 Trabalhos Relacionados

Para realização deste trabalho foram pesquisados além de outros materiais, artigos
relacionados ao assunto aqui proposto. Principalmente abordando as experiências no
processo de implantação do IPv6 nas diversas esferas, em especial nas Universidades
Brasileiras, justamente por se tratar de uma das recomendações do CGI.br (Comitê Gestor
da Internet no Brasil) em sua resolução que trata do tema (CGI.BR, 2013).
2.5.1 Um Modelo de Migração de Ambiente IPv4 para IPv6 em uma Rede

Acadêmica Heterogênea.
Nesta dissertação de Mestrado (BARRETO, 2015), o autor realiza um trabalho de
experimentação de implantação do IPv6 na rede da Universidade de Brasília (REDUnB).
O mesmo conseguiu expor uma grande fundamentação teórica sobre o tema, descre-
vendo as principais características do IPv6 e de seu antecessor, bem como das principais
técnicas de transição e coexistência entre IPv4 e IPv6.
Nos estudos realizados, tendo como base o cenário da Universidade de Brasília
(UnB) em 2014, onde segundo o autor, a Universidade dispunha ainda de uma quantidade
considerável de endereços IPv4, optou-se por adotar a técnica de Pilha Dupla, para a
metodologia pensada, permitindo uma migração gradual.
A REDUnB é uma rede ampla inclusive interligando campus geograficamente
distantes, sob uma tecnologia IPv4 e que segundo o autor, havia recebido naquele ano por
meio do Registro.br um bloco (/48) de endereços IPv6.
Para os testes de transição preferiu-se montar um laboratório físico para realização
2.5. Trabalhos Relacionados 57
dos experimentos e em uma fase inicial foi definido um plano de endereçamento e roteamento
de endereços. Esse laboratório em questão simulava o cenário real de rede da UnB e essa
metodologia foi escolhida justamente por fornecer essa possibilidade. O laboratório era
composto por switches e computadores que simulariam a rede, sendo que um deles foi
configurado como servidor DNS, um tablet com um software responsável por testes de
desempenho de redes.
Como métricas sugeridas e avaliadas o autor resolveu estudar a latência entre nós
da rede, utilizando para isso um cenário de comunicação de serviços HTTP. Um outro
cenário de avaliação proposto pelo autor mediria além da latência, índice MOS (Mean
Opinion Score), jitter, perdas de pacotes, indicador R-Value e medição de taxa de pacotes
fora da sequência, por meio de simulação de um ambiente VoIP.
Para mensuração da latência utilizando a comunicação e requisição de HTTP,
foram empregados os softwares Ping e HTTPing.
Análise com aplicativo Ping
Foram feitas um total de 30 capturas dividas em 3 grupos em dias diferentes com
um intervalo de no mínimo 5 minutos entre capturas. Obteve-se um resultado positivo
em relação a essa métrica, não havendo perdas de pacotes, com uma ressalva de que no
Protocolo IPv6 houve uma taxa ligeiramente maior em comparação ao obtido com o IPv4.
Em relação ao jitter, as análises colhidas pelo autor mostraram que o IPv6 obteve um
índice médio 17,38% maior que o IPv4.
Análise com aplicativo HTTPing
Foram aplicados métodos semelhantes para esse aplicativo, também totalizando
30 capturas. De acordo com o que foi pretendido pelo autor, obteve-se para o IPv6 um
resultado mais satisfatório. Contudo, apresentando taxa média superior em relação o índice
conseguido com o IPv4. Em relação ao jitter o IPv4 apresentou melhores resultados.
Em relação à simulação de uma rede VoIP, houve uma ligeira perda de pacotes nos
testes realizados sob o IPv6, mas aceitável. A mensuração do jitter esteve dentro do limite
aceitável e aconselhado. Os resultados sobre latência atribuía um resultado um pouco mais
elevado no IPv6 (32,38%) maior que no IPv4, no entanto, ainda dentro da faixa limite.
Os indicadores específicos para avaliação de serviços VoIP, empregados R-Value e MOS,
tiveram excelentes números, demonstrando um serviço de qualidade VoIP na rede.
Em relação aos resultados obtidos e com base nas métricas aplicadas pelo autor,
foi possível verificar que apesar da ligeira diferença de desempenho do IPv4 nos testes
com requisições HTTP e das variações no segundo experimento, permitiu observar o
comportamento e desempenho entre as duas versões e que segundo o autor utilizar um
ambiente físico para experimentação, permitiu aproximar de forma realista o cenário
vivenciado pela rede da UnB, apesar de não ter sido possível a implementação e testes de
outros tipos de serviços.

No geral, concluiu-se que nos testes realizados o IPv4 obteve um melhor desempenho
em relação ao IPv6, contudo, diante da situação atual a migração para a nova versão se
faz necessária em todas as esferas. A técnica escolhida para a migração de rede da UnB
foi a Pilha Dupla.
O autor verificou também o quanto ainda é precário a disponibilidade de serviços e
sites ofertados para IPv6, demonstrando que ainda há muito o que fazer para atingir um
cenário de transição de qualidade.
2.5.2 Proposta de Implantação do Protocolo IPv6 na Rede da Universidade

Federal de Lavras
Um segundo trabalho estudado foi realizado por (ABREU, 2014). Trata-se de uma
dissertação de conclusão do curso de Sistemas de Informação da Universidade Federal
de Lavras (UFLA) e pretendia realizar um levantamento da implantação do IPv6 na
Universidade.
Em um cenário semelhante à UnB, a UFLA também dispunha de uma quantidade
endereços IP ainda disponível no ano de elaboração do trabalho (2014), o que levou o
autor a escolher a técnica de Pilha Dupla.
Foi realizado uma pesquisa junto ao setor responsável da UFLA, a respeito de
informações pertinentes relacionadas ao tema, como plano de endereçamento, recursos etc.
Para realização e planejamento das pesquisas utilizou-se a rede implantada no DCC-UFLA
(Departamento de Ciência da Computação da Universidade Federal de Lavras). Onde já
havia a existência de um ponto IPv6 rodando em Pilha Dupla.
Buscou-se avaliar a latência e quantidade média de dispositivos que acessavam a rede
simultaneamente. Como já havia um ponto IPv6 foram testados também a disponibilidade
de serviços na tentativa de acesso a diversos sites por meio de IPv6 e o tempo de resposta
à solicitação. Para o cálculo da latência, o autor fez uso do aplicativo Ping.
Resultados Obtidos.
No acesso aos sites, pretendeu-se o acesso unicamente em IPv6 dos 20 sites mais
acessados no Brasil. Com base nos resultados verificou-se que dos 20 sites pesquisados,
nas 10 primeiras colocações, 30% não estava acessível por IPv6, chegando a 60% no total
pesquisado.
Foram feitas tentativas de acesso a sites como globo.com, Yahoo, Facebook, dentre
outros. Para os testes de latência, usando o aplicativo Ping, utilizou-se o disparo dos
comandos nos dois sites mais acessados: google.com e facebook.com, chegando aos seguintes
resultados.
Segundo o autor de acordo com os resultados houve uma diferença bem significativa
entre a utilização do IPv4 em relação ao IPv6 disparado contra o site: google.com. Por outro
lado, é praticamente imperceptível essa diferença quando disparado contra o facebook.com.
Como conclusão do trabalho segundo descrição do autor, foi permitido verificar
que a estrutura de serviços web ainda não estava estruturada por completo para serviços
puramente IPv6, com poucos sites acessíveis por esta tecnologia.
A implantação do IPv6 na UFLA era um projeto a ser considerado e aplicado,
obteve-se bons resultados nos testes realizados no laboratório do DCC, contudo, por
motivos que abrangiam hardware e o uso do firewall da instituição que não oferecia suporte
ao IPv6, não seria viável naquele momento estender a implantação da rede em toda
instituição.
2.5.3 Estudo da eficiência da comunicação IPv4 versus IPv6 na rede de

investigação e ensino Portuguesa RCTS entre Lisboa e Covilhã
Esse trabalho estudado é uma dissertação apresentada a Universidade Lusófona
de Humanidades e Tecnologias (ULHT), em Portugal defendida por (GALEGO et al.,
2016). Neste trabalho o autor pretendeu exemplificar as métricas relacionadas ao requisito
de Qualidade de Serviços envolvendo os protocolos IPv4 e IPv6, aplicados à rede de
investigação e ensino Portuguesa, entre a Universidade Lusófona e Universidade da Beira
Interior (UBI), localizada na cidade portuguesa de Covilhã.
Como métricas a serem avaliadas pelo autor estão a taxa de atraso, perda de
pacotes, e quantidade de pacotes transferidos, envolvendo a transferência de pacotes UDP,
TCP, comunicação VoIP e transmissão streaming de áudio e vídeo.
Segundo (GALEGO et al., 2016), a Rede Ciência, Tecnologia e Sociedade (RCTS)
possui alto desempenho voltada para experimentação e soluções avançadas de comuni-
cações, oferecendo vários serviços aos membros, que vão desde Universidades, Institutos
Politécnicos, etc. A rede já possui um bloco IPv6 atribuído pelos órgãos responsáveis locais
alocado e operando em Pilha Dupla.
Para o experimento utilizou-se 2 computadores, um ligado a roteadores em ULHT,
Lisboa e outro em UBI, Covilhã, conforme pode ser verificado na Figura 30 extraída de
seu trabalho.
Figura 30 – Topologia/Experiência.
Fonte:(GALEGO et al., 2016)
Serão apresentados os dados obtidos nos experimentos referentes à: transmissão

de dados streaming utilizando IPv4 e IPv6. O autor estabeleceu que os testes seriam
aplicados com duração de 30 minutos, de forma simultânea (transmissão de todos os fluxos
de dados). Um dos testes foi aplicado entre 15:30h e 16:00h definido com horário laboral e
outro entre 22:00h e 22:30h, em um horário pós-laboral, ambos ocorridos em 21/07/2016.
Em ambos os horários para o experimento envolvendo transmissão de tráfego
streaming, foram gerados 120,3 pacotes por segundo com tamanho médio de 1352,56 bytes
cada. Abaixo segue tabela comparativa com os dados extraídos da dissertação.
A Figura 31 mostra os resultados aplicados aos testes realizados na transmissão de
tráfego streaming em redes IPv4 e IPv6.
Figura 31 – Resultados trasmissão tráfego streaming.

Fonte: Dados extraídos de acordo com (GALEGO et al., 2016).
Em ambas os cenários de experimentação, houve um número um pouco maior de

pacotes transmitidos na rede IPv4, e em decorrência disso verifica-se que há uma taxa
ligeiramente maior na rede IPv4 nos tópicos de Atraso médio, variação média do atraso,
bytes recebidos.
Em relação à taxa de transferência, notamos uma variação semelhante entre
protocolos como uma pequena taxa maior atribuída ao IPv4. Fato observado também na
médias de pacotes transmitidos.
Já em relação ao descarte de pacotes foi notado uma substancial diferença entre
protocolos, chegando a 111 pacotes perdidos a mais na rede IPv6, verificado no cenário
Laboral, bem como uma ligeira diferença de perda de pacotes maior em IPv6 em horário
pós-laboral.
Nesse estudo, o foco do autor foi verificar a Qualidade de Serviços, apresentadas
nas duas redes. O que é um fator de extrema importância neste momento de transição.
Apesar de não ter apresentado aqui os resultados dos outros experimentos que o
autor realizou, o mesmo apurou por meio deles que o IPv6, obteve uma ligeira superioridade
em relação ao IPv4, considerando o cenário experimentado com base nas métricas definidas
e aferidas.
Baseado nos trabalhos aqui apresentados verificamos os seguintes pontos a seguir:
• Necessidade de implantação do protocolo IPv6, num cenário de extinção de endereços

IPv4;
• Preferência pela técnica de Pilha Dupla para esse momento de transição;
• Ligeira vantagem no quesito latência no protocolo IPv4, contudo, os índices atingidos

pelo IPv6, não são alarmantes;
• Necessidade de melhoria constante e disponibilidade de mais serviços na rede para

acesso IPv6. Isso mostra ainda uma deficiência enfrentada pelas empresas fornecedoras
desses serviços.
3 Metodologia
Após pesquisas sobre as diversas técnicas de transição, direcionamos os estudos

para os testes usando como base o cenário de redes do ICEA. Para isso foi realizado
o levantamento da rede do instituto. Após essa etapa, utilizamos o software CORE
para reproduzir o cenário e posterior emulação com algumas técnicas existentes. Os
resultados obtidos a cada execução dos testes foram utilizados para avaliação das métricas
e comparação entre protocolos e técnicas.
Um dos principais motivos ao usar testes é mostrar que após aplicadas as configu-
rações de uma técnica, é possível obter a comunicação entre os hosts na rede.
Utililizar um software para emulação de redes permite vantagens, como por exemplo:
• Possibilidade de montar diversas arquiteturas;
• Preservação da rede real, caso haja erros em configurações;
• Ambiente para testes de novas tecnologias antes de implementações;
• Economia em custos, ao não ter que comprar equipamentos para realização de testes.
3.1 Métricas
As seguintes métricas serão avaliadas:
• Latência: Tempo necessário que um pacote leva para trafegar entre a máquina
origem e destino.
• jitter: Segundo (FOROUZAN, 2009) jitter é a variação de atraso de um pacote

em um mesmo fluxo na rede. Cada pacote trafegado na rede pode sofrer tempos
diferentes de atraso até sua chegada ao destinatário. Taxas “descontroladas” de jitter
influenciam nas aplicações que reproduzem áudio e vídeo.
• Perda de Pacotes: Obter dados de taxa de pacotes que não chegaram ao seu
destino.
Essas são métricas importantes quando falamos de qualidade de serviço e comuni-

cação em redes. Elas podem afetar aplicações em tempo real, serviços de áudio e vídeo na
Internet (TANEMBAUM, 2003).
3.2. Softwares 63
3.2 Softwares
3.2.1 CORE
O emulador de redes CORE é desenvolvido por uma divisão de Pesquisas e Tecno-
logia da Boeing com apoio da Naval Research Laboratory (LAB, 2017).
Segundo (EQUIPE, 2015), através do CORE é possível criar arquiteturas diversas,
bem como interligá-las à cenários reais. Podemos também realizar simulações envolvendo
topologias por meio da integração de máquinas Unix e equipamentos de redes, como por
exemplo, roteadores.
O CORE proporciona um ambiente de trabalho bem enxuto, de fácil manuseio e
configuração, tornando possível também usá-lo em conjunto com outras ferramentas como
por exemplo, o Wireshark para análises de pacotes trafegados em uma rede. A Figura 32
representa o ambiente de trabalho do emulador CORE.
Figura 32 – Área de Trabalho, CORE.

64 Capítulo 3. Metodologia
3.2.2 iPerf
O software iPerf (IPERF, 2018) foi criado originalmente pelo National Laboratory
for Applied Network Research (NLANR), sob licença BSD usado para medições de largura
de banda em redes IP, além de funcionar também como um gerador de tráfego de redes.
Oferece suporte aos protocolos IPv4 e IPv6 e podem ser utilizados testes por meio
de UDP, TCP e SCTP (Stream Control Transmission Protocol). Nos testes realizados
obtêm-se parâmetros como perda de pacotes, jitter e largura de banda.
A Figura 33 demonstra o software iPerf funcionando, acima temos um terminal
executando um cliente iPerf, abaixo um servidor iPerf.
Figura 33 – Software iPerf operando.

3.3 Ping
Encontrado em diversos sitemas operacionais, o software Ping é empregado para
testar a conectividade entre os hosts em uma rede. Utiliza protocolo ICMP (Internet
Control Message Protocol). O teste consiste no envio de pacotes entre o host emissor,
3.4. Testes 65
que espera a resposta do host destinatário. Se houver comunicação entre eles, o emissor
receberá a resposta.
Segundo (BRITO, 2013a), além de testar a comunicação, é possível obter dados
úteis para avaliação de uma rede, como por exemplo, o valor de latência exibido em cada
linha de resposta, valores baixo, médio e alto de latência, (rtt min, avg e max). No sistema
operacional Linux o parâmetro mdev, presente no relatório final demonstra a medida de
do jitter.
3.4 Testes
Foram utilizados neste trabalho os testes nas seguintes técnicas: Pilha Dupla,
Tunnel Broker, 6over4, e GRE.
Os testes consistiram em utilizar o Ping para verificar a comunicação entre os hosts
no cenário de rede empregado. Após configuração de cada técnica foram executados 10
comandos Ping de forma sequencial de um host cliente ao servidor na rede. Em cada
comando foram emitidos 10 pacotes e assim mensurados os resultados. Através desse teste
é possível obtermos informações de Latência e jitter da rede.
Para medição de perda de pacotes foi utilizado o software iPerf. Os testes consistiram
em fazer trafegar pela rede uma quantidade de 200MB em modo cliente servidor. Ao final
obtivemos a quantidade de pacotes enviados e a perda de pacotes, caso haja.
Para os testes usando Tunnel Broker, foram efetuados os comandos de Ping contra
os servidores do site www.google.com, utilizando IPv4 e IPv6, tendo respondido servidores
com os endereços: IPv4 (172.217.28.131) e IPv6 (2800:3f0:4001:80c::2003). Foi utilizado
um notebook, com as seguintes configurações: sistema operacional Linux Ubuntu 16.04 Lts,
processador Intel CORE i7, 8GB de memória RAM (Random Access Memory).
Os gráficos finais gerados trazem uma comparação entre execução utilizando IPv4
e IPv6.
4 Experimentos e Resultados
Esta seção descreve o cenário de testes, resultados obtidos, apresentando uma

análise comparativa entre as técnicas escolhidas.
4.1 Cenário de Testes

Basicamente podemos representar o cenário de redes do ICEA em duas partes, a
conexão e comunicação de equipamentos via Ethernet e Wi-Fi. Na rede Ethernet estão
ligados os equipamentos dos laboratórios, secretarias, biblioteca e demais salas. Já a
rede Wi-Fi temos além das conexões da rede adminitrativa o acesso dos alunos através
da MinhaUfopWi.Fi. Para demonstração neste trabalho, nos preocupamos apenas na
representação da parte de entrada para a rede, ou seja, conexão dos Switches, Access
Points e roteadores. Não serão elencados aqui configurações relacionados à segurança,
algoritmos de roteamento, métodos de autenticação à rede, configurações de classificação e
endereçamento de pacotes em switches e roteadores.
O acesso à rede Wi-Fi é feito através da conexão sem fio dos equipamentos aos
diversos APs posicionados nos andares de cada prédio do instituto. Os APs estão conectados
aos switches. Os switches de cada 1o andar se conectam a um switch instalado no 2o andar
do Bloco B.
O campus do Instituto de Ciências Exatas e Aplicadas está localizado na cidade
de João Monlevade-MG e atualmente oferece os cursos de Engenharia da Computação,
Elétrica, Produção e Sistemas de Informação. É composto por 8 blocos. Os blocos em sua
maioria possuem 3 andares, exceto o bloco G (administrativo) que possui 4 andares. Neste
bloco funcionam as secretarias diversas, salas dos colegiados e dos professores, auditório,
biblioteca.
Para os experimentos utilizamos uma representação em menor porte desse cenário.
Decidimos por este tipo de abordagem pelo fato de legibilidade do desenho e principalmente
pelos problemas enfrentados com a questão de desempenho do emulador, como pode ser
melhor explicado na seção de Limitações neste texto. A Figura 34 mostra como ficou o
cenário de testes utilizados no CORE.
4.2. Pilha Dupla 67
Figura 34 – Representação do Cenário usado para testes.

O host Cliente1 representa os equipamentos que acessam a rede sem fio, já o

Cliente2 os equipamentos conectados via rede cabeada. Ao lado direito da figura temos
dois equipamentos representando a Internet.
4.2 Pilha Dupla

Ao utilizar a Pilha Dupla, temos todos equipamentos da rede configurados com as
duas pilhas do protocolo IP, (IPv4 e IPv6). Assim um host poderá se comunicar via IPv4
com outro host IPv4 na outra ponta, e vice-versa. Caso haja algum de erro e uma das
pilhas, a outra funcionará perfeitamente.
A Figura 35 representa o cenário de Pilha Dupla montado para testes. Os testes de
Ping partiram do Cliente-1 e Cliente-2 com destino ao host SERVIDOR-EXTERNO, que
está representando um host na Internet.
68 Capítulo 4. Experimentos e Resultados
Figura 35 – Representação Técnica de Pilha Dupla

A Figura 36 mostra os resultados de latência obtidos para Pilha Dupla.

Gráfico de Latência Cliente-1 - Utilizando Pilha Dupla
Figura 36 – Comparação de Latência - Computador Cliente-1 - Pilha Dupla

Em relação aos resultados de latência obtidos pelo Cliente-1 utilizando as duas

4.2. Pilha Dupla 69
pilhas do protocolo IP, percebemos que não houveram divergências muito grandes testes.
O IPv4 obteve médias menores nos 10 testes executados, variando entre 41,107ms
e 41,166ms e obteve média geral de 41,128ms contra 41,242ms do IPv6.
A Figura 37 mostra os resultados de jitter para Cliente-1.
Gráfico de Jitter Cliente-1 - Utilizando Pilha Dupla
Figura 37 – Comparação de Jitter - Computador Cliente-1 - Pilha Dupla

Na comparação de jitter médio obtido, já temos momentos de variação entre as

pilhas. Há testes em que o IPv4 obteve pior média de jitter, outros em que o IPv6 obteve
resultado pior.
Dois pontos com resultados discrepantes para cada protocolo: no teste 3 observamos
uma média de jitter de 0,030ms para IPv4 contra 0,226ms para o IPv6. O fato se inverte
no teste 7, onde o IPv6 obteve apenas 0,020ms de média contra 0,207ms do IPv4.
Para esse quesito, o IPv6 obteve maior número de testes com menores médias de
jitter e média de geral de 0,154ms.
A Figura 38 exibe os resultados de latência para Cliente-2.

Gráfico de Latência Cliente-2 - Utilizando Pilha Dupla
Figura 38 – Comparação de Latência - Computador Cliente-2 - Pilha Dupla

Comparando os resultados do Cliente-2 que se comunica através de uma conexão

cabeada, em relação à latência nas duas pilhas do protocolo observamos valores médios
próximos nos testes realizados.
Cada protocolo obteve 5 resultados com melhor média em relação ao outro. A
média geral obtida pelo IPv4 foi de 1,030ms contra 1,033ms do IPv6.
4.3. 6over4 71
A Figura 39 mostra os resultados de jitter para Cliente-2 utilizando Pilha Dupla.

Gráfico de Jitter Cliente-2 - Utilizando Pilha Dupla
Figura 39 – Comparação de Jitter - Computador Cliente-2 - Pilha Dupla

Valores médios de jitter obtidos pelo Cliente-2 nas duas pilhas de protocolo não
apresentaram valores tão discrepantes em relação de um ao outro. Se observarmos que no
teste 6 houve um empate nas taxas, podemos perceber que em relação à quantidade de
testes emitidos a pilha IPv6 obteve médias mais baixas, incluive com média geral obtida
de 0,046ms, quando o IPv4 obteve 0,048ms.
4.3 6over4
No cenário montado para representação da técnica 6over4, temos os hosts, Cliente-
1, Cliente-2 e Servidor-Externo configurados com as duas pilhas do protocolo. Contudo,
o meio para que esses hosts possam se comunicar possuem apenas endereços IPv4, e
precisamos interligá-los por meio de IPv6. É necessário que haja uma forma de fazer esses
hosts se comunicarem. A Figura 40 mostra a representação do cenário 6over4.
Figura 40 – Representação Técnica 6over4.

A Figura 41 exibe os resultados obtidos para latência pelo Cliente-1 utilizando

6over4.
Gráfico de Latência Cliente-1 - Utilizando 6over4
Figura 41 – Comparação de Latência - Computador Cliente-1 - 6over4

4.3. 6over4 73
Dados obtidos pelo Cliente-1 utilizando 6over4, mostraram um melhor desempenho

do IPv4 em relação ao IPv6, estando essa pilha à frente com médias menores em todos os
10 testes executados. A média geral do IPv4 foi de 41,185ms, o IPv6 atingiu média geral
de 41.252ms.
A Figura 42 mostra os resultados obtidos pelo Cliente-1 para jitter utilizando
6over4.
Gráfico de Jitter Cliente-1 - Utilizando 6over4
Figura 42 – Comparação de Jitter - Computador Cliente-1 - 6over4.

As médias de jitter comparativas para o Cliente-1, em ambos os protocolos utilizando

6over4 demonstraram um empate se relacionarmos à quantidade de testes executados.
No teste 9, notamos que o IPv6 se destaca negativamente com uma média mais
elevada em relação as demais testes. Notamos no teste 4 uma média quase 3 vezes maior de
jitter por parte da pilha IPv4 em relação ao IPv6. Esse fato também pode ser observado
no teste 6 porém com média maior a pilha IPv6, obtendo 0,256ms de média. IPv4 e IPv6
obtiveram médias gerais bem próximas: 0,196ms e 0,197ms respectivamente.
A Figura 43 mostra os resultados de latência obtidos pelo Cliente-2 utilizando esta

técnica.
Gráfico de Latência Cliente-2 - Utilizando 6over4
Figura 43 – Comparação de Latência - Computador Cliente-2 - 6over4.

Em relação ao Cliente-2, os testes de latência utilizando 6over4, obtivemos um

menores médias com IPv4, estando à frente em 9 dos 10 testes executados. Com média
geral de 1,067ms contra 1,147ms utilizando IPv6. A Figura 44 mostra os resultados de
jitter para o Cliente-2 utilizando 6over4.
4.3. 6over4 75
Gráfico de Jitter Cliente-2 - Utilizando 6over4
Figura 44 – Comparação de Jitter - Computador Cliente-2 - 6over4.

Valores de média de jitter do Cliente-2, demonstraram um melhor desempenho

nessa métrica usando IPv4, com menor média em 6 dos 10 testes executados. No teste
1 o IPv4 apresentou resultado quase 4 vezes maior de média em relação ao IPv4, com
resultado cerca de 26% mais elevado. A média geral dos protocolos foram de 0,045ms para
IPv4 e 0,042ms para IPv6.
4.4 GRE
O cenário montado para os testes utilizando GRE é idêntico ao usado em 6over4, o
que diferencia as técnicas é que em GRE podem ser encapsulados vários tipos de protocolos,
ao contrário do 6over4, onde só é permitido o encapsulamento do protocolo IPv6. Após
inseridas as configurações do túnel obtivemos os seguintes resultados.
A Figura 45 mostra as médias de latência do Cliente-1.
Gráfico de Latência Cliente-1 - Utilizando GRE
Figura 45 – Comparação de Latência - Computador Cliente-1 - GRE.

Pelos valores de média resultantes nas duas pilhas utilizadas, sendo o IPv6 executado
por meio de um túnel GRE, a pilha IPv4 obteve melhor desempenho em todos os testes.
Visto que a difernça de valores não são discrepantes, a pilha IPv6 também obteve boas
médias em relação às médias atingidas com IPv4. Já no teste 9, houve um índice médio
um pouco maior para IPv6. Aqui a média geral do para IPv4 foi de 41.171ms frente a
41,275ms obtida pelo IPv6.
4.4. GRE 77
A Figura 46 mostra as médias de jitter do Cliente-1.

Gráfico de Jitter Cliente-1 - Utilizando GRE
Figura 46 – Comparação de Jitter - Computador Cliente-1 - GRE.

Já em relação às médias de jitter, quando comparadas a quantidade de testes

executados, obtemos um empate entre os protocolos utilizados. Contudo, observamos uma
taxa bem elevada de média jitter do IPv6 em relação ao IPv4, atingindo taxa de pouco
mais de 6 vezes superior no teste 7. O mesmo fato pode ser observado no teste 9 com taxa
de um pouco mais de 2,4 vezes.
A médias gerais obtidas pelos protocolos IPv4 e IPv6 foram de 0,206ms e 0,234ms
respectivamente.
A Figura 47 mostra as médias de latência do Cliente-2.

Gráfico de Latência Cliente-2 - Utilizando GRE
Figura 47 – Comparação de Latência - Computador Cliente-2 - GRE

Quando comparamos os resultados obtidos pelo Cliente-2 utilizando a técnica GRE,

obtivemos menores médias com IPv4, em todos testes executados, mas por apresentar valo-
res aproximados, não podemos considerar que a pilha IPv6 tenha se saído mal. Observamos
média geral de 1,061ms pelo IPv4 e 1,118ms com IPv6.
4.4. GRE 79
A Figura 48 mostra as médias de jitter do Cliente-2.

Gráfico de Jitter Cliente-2 - Utilizando GRE
Figura 48 – Comparação de Jitter - Computador Cliente-2 - GRE

Em relação ao jitter, o IPv4 esteve melhor em 8 dos 10 testes. Destaque para o

teste 4 onde o resultado foi cerca de 7 vezes menor que o IPv6 e no teste 6, com resultado
ainda mais expressivo, cerca de quase 14 vezes menor. Já no teste 10, a pilha IPv6 obteve
índice cerca de 2,75 vezes menor.
As médias gerais dentre os testes execitados foram de 0,027ms utilizando IPv4 e de
0,042ms com IPv6.
4.5 Tunnel Broker

Para este trabalho foram utilizados os serviços da Hurricane Electric. Para isso, é
necessário que se faça um pequeno cadastro no site da empresa, https://tunnelbroker.net/.
Antes de realizar as configurações para acesso, foram executados testes de Ping
contra dois serviços na Internet e tentativas de acessar sites que permitem acesso via IPv6.
A Figura 49 mostra a falha na tentativa de Ping6 contra os serviços na Internet.
Figura 49 – Tentativa de Ping IPv6 à serviços de Internet.

Após a confirmação de configuração do Tunnel, foram feitos os testes Ping contra

os mesmos serviços, agora obtendo êxito, conforme pode ser visto na Figura 50:
Figura 50 – Teste de Ping IPv6 com êxito após configuração de Tunnel Broker
4.5. Tunnel Broker 81
Já na Figura 51 temos o êxito do acesso ao site http://ipv6.br/, via IPv6.
Figura 51 – Teste de acesso com IPv6 bem sucedido a um site.

A mesma metodologia descrita na seção Testes, também foi empregada aqui. O

intuito é obter os resultados das métricas avaliadas fora do ambiente virtualizado do
emulador CORE.
A Figura 52 mostra os resultados obtidos para latência utilizando esta técnica.

Gráfico de Latência - Utilizando Tunnel Broker
Figura 52 – Média de Latência IPv4xIPv6 usando Tunnel Broker.

Os resultados para Latência apresentaram menores médias utilizando IPv4. Com

média geral de 24,954ms frente a 239,306ms obtidos com IPv6. O fato das médias utilizando
IPv6 serem tão elevadas pode ser explicado justamente porque todo o conteúdo trafegado
na rede necessita passar primeiro pela estrutura do servidor contratado para oferecer os
serviços, tornando a rede lenta (FLORENTINO, 2012).
4.5. Tunnel Broker 83
A Figura 53 apresenta resultados para a jitter utilizando Tunnel Broker.

Gráfico de itter - Utilizando Tunnel Broker
Figura 53 – Média Jitter IPv4xIPv6, usando Tunnel Broker

Já no quesito de jitter, a pilha IPv4 obteve nemores médias em 7 dos 10 testes

executados. Atingindo média geral de 5,376ms contra 5,387ms do IPv6.
Resultados de Perda de Pacotes X Técnica Utilizada.
A taxa de perda de pacotes em qualquer rede é um item importante. Altas taxas
de pacotes perdidos podem afetar o desempenho da rede em inúmeros quesitos como, por
exemplo, comunicação via Internet e streaming de vídeos.
Para as técnicas de Pilha Dupla, 6over4 e GRE, que foram implementadas utilizando
o CORE, os testes consistiram em fazer trafegar pela rede uma quantidade de 200MB
de dados gerados (datagramas UDP) pelo iPerf e ao final foram avaliados se houveram
perdas. Foram avaliadados os dois computadores clientes com IPv4 e IPv6.
Já para a técnica de Tunnel Broker, foi utilizado um servidor gratuito na Internet,
que responde às requisições via IPv4 e IPv6 de clientes iPerf. Escolhemos o servidor que
está configurado no endereço iperf.he.net, localizado na Califórnia (USA) da Hurricane
Electric. A dinâmica dos testes foi a mesma anterior.
Os seguintes resultados obtidos estão representados na Figura 54.
Figura 54 – Relação de Perda de Pacotes X Pacotes Enviados.

Um dado importante ao analisar a figura, é que o número de pacotes gerados e

enviados pela rede nem sempre foi o mesmo. No entanto, a quantidade de informação
trafegada foi de 200 MBytes.
Em relação às técnicas que foram testadas no CORE, de maneira geral podemos
verificar que ao utilizarmos Pilha Dupla, obtivemos um melhor resultado. Do total de
102332 pacotes enviados, considerando os clientes 1 e 2, resultaram em 26481 pacotes
perdidos, o que leva a uma média de 25,87% de perda. Nos testes utilizando 6over4,
obtivemos média de 26,47% e com túnel GRE, 26,53% de perda total.
Os piores índices obtidos nesse quesito foram ao utilizar a técnica de Tunnel Broker,
gerando médias elevadas de perda de pacotes. Dos 51070 pacotes totais enviados, 45377
foram perdidos, uma taxa média de 88,85%.
4.6. Limitações 85
A Figura 55 mostra a porcentagem de perda de pacotes em cada técnica utilizada.
Figura 55 – Percental de Perda de Pacotes

Aqui podemos ver o desempenho de cada técnica, mesmo com resultados bem
próximos comparando as técnicas testadas no CORE, a técnica de Pilha Dupla teve
desempenho pouco melhor. Já ao utilizar Tunnel Broker, obtivemos índice de 94% de
perda de pacotes nos testes com IPv6.
Com base nos dados apresentados concluímos que, comparando os resultados em
relação ao números de testes executados em cada técnica nos quesitos de Latência e jitter,
os melhores resultados foram obtidos utilizando IPv4. Contudo, observamos que a diferença
entre pilhas é muita vezes estreita, com episódios de picos em alguns testes para cada lado,
assim, não podemos dizer que ao utilizar IPv6 teremos índices baixos sempre, a ponto de
impedir seu uso.
Em relação à perda de pacotes, também obtivemos melhores resultados utilizando
IPv4, apresentando menores taxas em todos os testes executados.
4.6 Limitações
No decorrer do trabalho, um dos problemas enfrentados foi quanto ao desempenho
do CORE para carregar e executar uma representação do cenário de redes com muitos com-
ponentes. Quando inserimos os componentes montados para a rede do ICEA e interligamos
os mesmos, o processo de execução do software se tornava extremamente lento, chegando

ao ponto de travamento do CORE e até mesmo em alguns casos da própria máquina. Isso
pode ter explicação no fato de estarmos trabalhando com emulação/virtualização, processo
que muitas vezes exige alto poder de processamento de hardware.
Devido a essa limitação resolvemos usar nos nossos testes parte da representação
do cenário, como explicado na seção Metodologia.
Outra limitação foi encontrada ao tentarmos representar a técnica de Tradução,
NAT64/DNS64. A preparação para este teste teria como base experimentos apresentados
em (EQUIPE, 2015). Para que pudesse funcionar a tradução de pacotes IPv6 para IPv4,
seria necessário configurarmos o TAYGA (LUTCHANSKY, 2018) software livre que realiza
esse processo. Já para executar o DNS64 (BAGNULO et al., 2011), usaríamos o software
BIND (CONSORTIUM, 2018). Contudo, após realizarmos a instalação desses programas e
posteriormente tentar configurá-los para os testes, houveram algumas incompatibilidades
que não conseguimos sanar, por este motivo não foi contemplado nesse trabalho os testes
com uma técnica de Tradução.
Não foram aplicados testes aleatórios pelos seguintes motivos: utilizando o CORE
justamente por ser um ambiente virtual dependíamos apenas do processamento do software
e do computador hospedeiro. Já os testes com Tunnel Broker tentamos aplicar os comandos
em momentos diferentes, dia e horário. Contudo, os servidores que estavam respondendo às
duas requisições do protocolo, nem sempre estavam em operação. Assim, quando estavam
em operação aproveitamos para realizar os comandos de forma sequencial.
87
5 Conclusão
Os estudos empregados para realização deste trabalho, buscaram mostrar de

forma geral algumas das principais características do IPv6, das Técnicas de Transição e
Coexistência em redes IPv4/IPv6, apresentando um comparativo entre algumas dessas
técnicas usando como base um modelo do cenário de redes do Instituto de Ciências Exatas
e Aplicadas.
O IPv6 vem para suprir um dos grandes problemas enfrentados hoje mundialmente
em relação à Internet, a falta de endereços IPv4. O que certamente irá permitir o iminente
avanço e o crescimento natural da rede com a inclusão de novas tecnologias como Internet
of Things, bem como demanda por novos usuários. Com o espaço de endereçamento
oferecido pelo IPv6 é possivel gerar cerca de 340 undecilhões de IPs.
As técnicas de transição estão subdivididas em 3 categorias: Pilha Dupla, Tune-
lamento e Tradução. Ao utilizar Pilha Dupla, todos os equipamentos na rede estarão
operando com as duas versões do protocolo simultâneamente. Essa foi a técnica escolhida
para um processo gradual de transição. Um conceito geral sobre tunelamento, é permitir
que redes operando com versões diferentes do protocolo possam se comunicar. Todo o
tráfego gerado irá transitar por um túnel entre as redes. Há diversas implementações
dentro dessa categoria. Já em Tradução percebemos a utilização do NAT, uma medida
paliativa à falta de endereços IPv4.
Foram testadas neste trabalho as seguintes implementações, Pilha Dupla, túneis
6over4 e GRE, utilizando o Emulador CORE, onde reproduzimos parte do cenário de
rede do instituto e realização dos testes. Foi utilizado também uma configuração de
Tunnel Broker oferecido pela Hurricane Electric. No decorrer dos estudos, enfrentamos
algumas limitações, principalmente na queda de desempenho do emulador ao executar
um cenário com muitos hosts configurados, bem como, ao tentar representar a técnica de
Tradução NAT64/DNS64, duas implementações que trabalham em conjunto na tradução
de pacotes. Não foi possível a correta configuração dos softwares adicionais necessários
para o funcionamento. Devido a e est,e fato, não foi contemplado uma prática envolvendo
uma técnica de Tradução. Através dos testes foram mensurados: Latência, jitter e Perda
de Pacotes, sendo as duas primeiras métricas usando o aplicativo Ping e o software iPerf
para perda de pacotes.
De forma geral, os testes apontaram um melhor desempenho do IPv4, sendo a Pilha
Dupla apresentando números mais satisfatórios em relação às demais técnicas abordadas.
Contudo, obtivemos resultados bem parecidos em inúmeros testes, inclusive com valores
favoráveis ao IPv6, assim, não podemos afirmar que ao utilizar IPv6 teremos resultados
88 Capítulo 5. Conclusão
ruins sempre.
Como trabalhos futuros, propõe-se os testes dessas e outras técnicas no ambiente
real de rede do ICEA, para um eventual processo de migração/implantação do IPv6.
Em suma, no mundo todo está crescendo a adoção do novo protocolo de forma gra-
dual, mesmo com todo atraso existente. Implantar IPv6 é uma necessidade imprescindível
em todos os âmbitos, assim, promoveremos o crescimento da Internet.
89
Referências
ABLEY, J.; SAVOLA, P.; NEVILLE-NEIL, G. Deprecation of Type 0 Routing Headers in

IPv6. 2007. Disponível em: <https://tools.ietf.org/html/rfc5095>. Citado na página 39.
ABREU, D. H. S. Proposta de implantação do protocolo ipv6 na rede da universidade

federal de lavras. Lavras: [s.n.], 2014. Citado na página 58.
ACOSTA, A. et al. IPv6 para operadores de Red. [S.l.: s.n.], 2014. ISBN 978-987-45725-0-9.
Citado na página 51.
BAGNULO, M.; MATTHEWS, P.; BEIJNUM, I. van. Stateful NAT64: Network

address and protocol translation from IPv6 clients to IPv4 servers. 2011. Disponível em:
<https://tools.ietf.org/html/rfc6146>. Citado na página 52.
BAGNULO, M. et al. DNS64: DNS extensions for network address translation from IPv6
clients to IPv4 servers. 2011. Disponível em: <https://tools.ietf.org/html/rfc6147>.
Citado 2 vezes nas páginas 52 e 86.
BAO, C. et al. IPv6 addressing of IPv4/IPv6 translators. 2010. Disponível em:

BAO, C. et al. IP/ICMP translation algorithm. 2016. Disponível em: <https:

//tools.ietf.org/html/rfc6145>. Citado na página 54.
BAO, C. et al. The China education and research network (CERNET) IVI translation
design and deployment for the IPv4/IPv6 coexistence and transition. 2011. Disponível em:
BARRETO, J. d. S. Um modelo de migração de ambiente IPv4 para IPv6 em uma rede

acadêmica heterogênea. Dissertação (Dissertação de Mestrado) — Universidade de Brasília,
Instituto de Ciências Exatas, Departamento de Ciência da Computação, 2015. Citado 3
vezes nas páginas 34, 37 e 56.
BRITO, S. H. B. Interpretação dos Resultados do Ping. 2013. Disponível em:

<http://labcisco.blogspot.com/2013/05/interpretacao-dos-resultados-do-ping.html>.
BRITO, S. H. B. IPv6-O novo protocolo da Internet. São Paulo: Novatec Editora, 2013.
Citado 8 vezes nas páginas 28, 41, 42, 43, 46, 47, 48 e 51.
CARPENTER, B.; MOORE, K. Connection of IPv6 domains via IPv4 clouds. 2001.
Disponível em: <https://www.ietf.org/rfc/rfc3056.txt>. Citado na página 46.
CARUGI, M.; CLERCQ, J. D.; OOMS, D. BGP-MPLS IP Virtual Private Network (VPN)
Extension for IPv6 VPN. 2006. Disponível em: <https://tools.ietf.org/html/rfc4659>.
CARVALHO, D. D. P. d. Implantação e análise do protocolo ipv6 com foco na mobilidade.

2015. Citado na página 51.
90 Referências
CGI.BR, C. G. da Internet no B. Resolução CGI.br/RES/2013/033. 2013. Disponível em:

<https://www.cgi.br/resolucoes/documento/2013/CGI.br_Resolucao_2013_033.pdf>.
CHEN, M. et al. IPv4 Residual Deployment via IPv6-A Stateless Solution (4rd). 2015.
Disponível em: <https://tools.ietf.org/html/rfc7600>. Citado na página 49.
CITTADINI, L. et al. The A+ P Approach to the IPv4 Address Shortage. 2011. Disponível
em: <https://tools.ietf.org/html/rfc6346>. Citado na página 55.
COMER, D. Interligação de Redes com TCP/IP–: Princípios, Protocolos e Arquitetura.

[S.l.]: Elsevier Brasil, 2015. v. 1. Citado na página 34.
CONSORTIUM, I. I. S. BIND - Versatile, Classic, Complete Name Server Software. 2018.

Disponível em: <http://www.isc.org/downloads/bind/>. Citado na página 86.
CORDEIRO, E. S. Comparação de técnicas de transição do ipv4 para o ipv6. 2014.

DESPRES, R. IPv6 rapid deployment on IPv4 infrastructures (6rd). 2010. Disponível em:
DURAND, A. et al. Dual-stack lite broadband deployments following IPv4 exhaustion.

2011. Disponível em: <https://tools.ietf.org/html/rfc6333>. Citado 2 vezes nas páginas
48 e 49.
EGEVANG, K.; FRANCIS, P. The IP network address translator (NAT). [S.l.], 1994.
ELECTRIC, H. Hurricane Electric Free IPv6 Tunnel Broker. 2018. Disponível em:
<https://tunnelbroker.net/>. Citado na página 32.
EQUIPE, N. Laboratório de IPv6: aprenda na prática usando um emulador de redes. São

Paulo: Novatec Editora, 2015. Citado 2 vezes nas páginas 63 e 86.
FAUCHEUR, F. L. et al. Connecting IPv6 Islands over IPv4 MPLS Using IPv6 Provider
Edge Routers (6PE). 2007. Disponível em: <https://tools.ietf.org/html/rfc4798>. Citado
na página 50.
FLORENTINO, A. A. IPv6 na prática. São Paulo: Linux New Media do Brasil, 2012.
Citado 4 vezes nas páginas 42, 45, 53 e 82.
FOROUZAN, B. A. Comunicação de dados e redes de computadores. [S.l.]: AMGH

Editora, 2009. Citado na página 62.
GALEGO, N. M. C. et al. Estudo da eficiência da comunicação IPv4 versus IPv6 na rede

de investigação e ensino Portuguesa RCTS entre Lisboa e Covilhã. Dissertação (Mestrado)
— Universidade Lusofona de Humanidades e Tecnologias, Escola de Comunicacao,
Arquitetura, Artes e Tecnologias de Informacao, Lisboa, 2016. Citado 2 vezes nas páginas
59 e 60.
GILLIGAN, R. E.; NORDMARK, E. Basic transition mechanisms for IPv6 hosts and
routers. 2005. Disponível em: <https://tools.ietf.org/html/rfc4213>. Citado na página
43.
Referências 91
GUARDINI, I.; DURAND, A.; LENTO, D. IPv6 Tunnel Broker. 2001. Disponível em:
HANKS, S. et al. Generic routing encapsulation (GRE). 2000. Disponível em:
HINDEN, R. Internet protocol, version 6 (IPv6) specification. 2017. Disponível em:
<https://tools.ietf.org/html/rfc8200>. Citado 2 vezes nas páginas 36 e 37.
HUITEMA, C. Teredo: Tunneling IPv6 over UDP through network address translations
(NATs). 2006. Disponível em: <https://www.ietf.org/rfc/rfc4380.txt>. Citado na página
47.
IANA. About us. 2018. Disponível em: <https://www.iana.org/about>. Citado na
página 27.
ICANN. What Does ICANN Do? 2018. Disponível em: <https://www.icann.org/
resources/pages/what-2012-02-25-en>. Citado na página 27.
POSTEL, J. (Ed.). RFC 791 Internet Protocol - DARPA Inernet Programm, Protocol
Specification. [S.l.], 1981. Citado 2 vezes nas páginas 27 e 34.
IPERF. iPerf - The ultimate speed test tool for TCP, UDP and SCTP. 2018. Disponível
em: <https://iperf.fr/>. Citado na página 64.
IPV6.BR. Previsão de esgotamento de endereços IPv4 nos RIR. 2018. Disponível em:
<http://ipv6.br/>. Citado na página 29.
KEMP, S. Digital in 2018: World’s internet users pass the 4 billion mark. 2018. Disponível
em: <https://wearesocial.com/blog/2018/01/global-digital-report-2018>. Citado na
página 27.
KUARSINGH, V. et al. Assessing the Impact of Carrier-Grade NAT on Network
Applications. 2013. Disponível em: <https://tools.ietf.org/html/rfc7021>. Citado na
página 55.
LAB, U. N. R. Common Open Research Emulator (CORE). 2017. Disponível em:
<https://www.nrl.navy.mil/itd/ncs/products/core>. Citado na página 63.
LACNIC. Projeção de esgotamento - Fase 3. 2018. Disponível em: <http:
//www.lacnic.net/1077/3/lacnic/fases-de-esgotamento-do-ipv4>. Citado 2 vezes nas
páginas 29 e 30.
LUTCHANSKY, N. TAYGA - Simple, no-fuss NAT64 for Linux. 2018. Disponível em:
<http://www.litech.org/tayga/>. Citado na página 86.
MAWATARI, M.; KAWASHIMA, M.; BYRNE, C. 464XLAT: Combination of stateful and
stateless translation. 2013. Disponível em: <https://tools.ietf.org/html/rfc6877>. Citado
na página 53.
NIC.BR. Transição. 2012. Transição. Disponível em: <http://ipv6.br/post/transicao/>.
Acesso em: 23 mar. 2017. Citado 7 vezes nas páginas 43, 44, 45, 47, 50, 53 e 54.
SANTOS, R. R. d. et al. Curso ipv6 básico. IPv6. br, São Paulo, 2012. Citado 17 vezes
nas páginas 30, 37, 38, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 54, 55 e 56.
92 Referências
TANEMBAUM, A. S. Redes de computadores-quarta edição. Amsterdam: Vrije

Universiteit, 2003. Citado na página 62.
TEMPLIN, F. et al. Intra-site automatic tunnel addressing protocol (ISATAP). 2005.

Disponível em: <https://tools.ietf.org/html/rfc5214>. Citado na página 48.
WETHERALL, J.; TANENBAUM, A. Redes de computadores. 5a edição. Rio de Janeiro:

Editora Campus, 2011. Citado 2 vezes nas páginas 33 e 34.
Apêndices
APÊNDICE A – Configurações Utilizadas
A.1 6over4
Cliente1
i p addr add 2 0 0 1 : 1 : : 2 0 dev l o

i p t u n n e l add toSERV mode s i t t t l 64 remote 1 0 . 0 . 1 . 1 0
local 200.239.153.20
i p l i n k s e t dev toSERV up
i p −6 r o u t e add 2 0 0 1 : 3 : : 1 0 dev toSERV
SERVIDOR-EXTERNO
i p addr add 2 0 0 1 : 3 : : 1 0 dev l o

i p t u n n e l add t o C l i e n t e 1 mode s i t t t l 64 remote 2 0 0 . 2 3 9 . 1 5 3 . 2 0
local 10.0.1.10
i p l i n k s e t dev t o C l i e n t e 1 up
i p −6 r o u t e add 2 0 0 1 : 1 : : 2 0 dev t o C l i e n t e 1
Cliente2
i p addr add 2 0 0 1 : 0 : : 2 0 dev l o

i p t u n n e l add toSERV mode s i t t t l 64 remote 1 0 . 0 . 1 . 1 0
local 200.239.152.20
SERVIDOR-EXTERNO
i p addr add 2 0 0 1 : 3 : : 1 0 dev l o

i p t u n n e l add t o C l i e n t e 2 mode s i t t t l 64 remote 2 0 0 . 2 3 9 . 1 5 2 . 2 0
local 10.0.1.10
A.2. GRE 95
A.2 GRE
Cliente1
i p addr add 2 0 0 1 : 1 : : 2 0 dev l o

i p t u n n e l add toSERV mode g r e t t l 64 remote 1 0 . 0 . 1 . 1 0
local 200.239.153.20
SERVIDOR-EXTERNO
i p addr add 2 0 0 1 : 3 : : 1 0 dev l o

i p t u n n e l add t o C l i e n t e 1 mode g r e t t l 64 remote 2 0 0 . 2 3 9 . 1 5 3 . 2 0
local 10.0.1.10
Cliente2
i p addr add 2 0 0 1 : 0 : : 2 0 dev l o

i p t u n n e l add toSERV mode g r e t t l 64 remote 1 0 . 0 . 1 . 1 0
local 200.239.152.20
SERVIDOR-EXTERNO
i p addr add 2 0 0 1 : 3 : : 1 0 dev l o

i p t u n n e l add t o C l i e n t e 2 mode g r e t t l 64 remote 2 0 0 . 2 3 9 . 1 5 2 . 2 0
local 10.0.1.10
96 APÊNDICE A. Configurações Utilizadas
A.3 Tunnel Broker
Cadastro no site Hurricane Electric
Para utilizar o serviço de túnel IPv6 da Hurricane Electric é necessário realizaro

um cadastro no site https://tunnelbroker.net/.
Na primeira tela do site, você deverá clicar em Register para ser direcionado à
página de cadastro, como pode ser visto nas Figuras 56 e 57.
Figura 56 – Tela Inicial.

Fonte: https://tunnelbroker.net/
Figura 57 – Tela Cadastro.

A.3. Tunnel Broker 97
Após o cadastro, basta clicar no botão de Login para ter acesso à página de
configuração o túnel. Clique em Create Regular Tunnel, forneça as informações de seu
endereço IPv4 e o servidor que deseja se conectar, Figura 58. Logo abaixo clique em Create
Tunnel.
Figura 58 – Criação do túnel.

Logo após será exibida uma tela contendo as informações do túnel criado, como
pode ser verificado na Figura 59.
Figura 59 – Resumo das configurações do túnel.

98 APÊNDICE A. Configurações Utilizadas
Em Examples Configurations escolha o sistema operacional, logo após será gerado

o código cliente para ser implementando em seu computador, Figura 60.
Figura 60 – Escolha do SO.

Para o nosso exemplo foi escolhido a opção Linux-net-tools, como demonstrado na

figura 61.
Figura 61 – Informações de configuração do túnel.

A.3. Tunnel Broker 99
Basta colar o código gerado em um Terminal em seu computador para configurar o

túnel. Como pode ser visto na Figura 62.
Figura 62 – Informações de configuração do túnel no terminal Linux.

APÊNDICE B – Médias gerais e cálculo de
Desvio Padrão
Aqui estão descritos os resultados das médias gerais e desvio padrão para as pilhas
IPv4 e IPv6 utilizadas nos testes.
Pilha Dupla
IPv4 IPv6 IPv4 IPv6
Média Geral em ms Desvio Padrão
Cliente1 Latência 41,128 41,242 0,0159565 0,0152118
Jitter 0,162 0,154 0,0603012 0,0722534
IPv4 IPv6 IPv4 IPv6

Jitter 0,048 0,046 0,0103388 0,0082250
6over4
IPv4 IPv6 IPv4 IPv6
Jitter 0,196 0,197 0,0547485 0,0784098

Latência 1,067 1,117 0,0158509 0,0065355
Jitter 0,045 0,042 0,0415577 0,0070463

GRE
IPv4 IPv6 IPv4 IPv6
Jitter 0,206 0,234 0,0678024 0,1571129
IPv4 IPv6 IPv4 IPv6

Jitter 0,027 0,042 0,0145685 0,0267477
Tunnel Broker
IPv4 IPv6 IPv4 IPv6
Notebook Latência 24,954 239,306 8,2303400 2,9713640
Jitter 5,376 5,387 13,2823622 8,0516718

Anexos
ANEXO A – Planta de Implantação do
ICEA
A projeto à seguir mostra a planta de implantação do ICEA.

MONOGRAFIA EstudoAplicaçãoTécnicas

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

MONOGRAFIA EstudoAplicaçãoTécnicas

Enviado por

Direitos autorais:

Formatos disponíveis

Universidade Federal de Ouro Preto

Instituto de Ciências Exatas e Aplicadas

Estudo da Aplicação das Técnicas de

Lúcio Flávio de Miranda

Estudo da Aplicação das Técnicas de Transição

Orientador: Theo Silva Lins

Monografia apresentada ao curso de Sistemas de Infor-

Universidade Federal de Ouro Preto

104f.: il.: color; grafs; tabs; mapas.

Orientador: Prof. MSc. Theo Silva Lins.

Monografia (Graduação). Universidade Federal de Ouro Preto. Instituto de

1. Arquitetura de redes. 2. Rede de computador - Protocolos. 3. Comutação

Catalogação: ficha.sisbin@ufop.edu.br CDU: 004.7

Agradeço primeiro a Deus por tudo.

Palavras-chaves: IPv4, IPv6, Técnicas de Transição, CORE, Latência, Perda de Pacotes,

Figura 1 – Representação geográfica das RIRs. . . . . . . . . . . . . . . . . . . . . 28

Tabela 1 – Área de abrangência das RIRs. . . . . . . . . . . . . . . . . . . . . . . 28

AFRINIC African Network Information Centre

AFTR Address Family Transition Router

APNIC Asia Pacific Network Information Centre

ARIN American Registry for Internet Numbers

ARPANET Advanced Research Projects Agency Network

A+P Address Plus Port

BSD Berkeley Software Distribution

B4 DS-Lite Basic Bridging BroadBand

CERNET2 China Education and Research Network

CIDR Classless Inter-Domain Routing

CGI.br Comitê Gestor da Internet no Brasil

CGN Carrier Grade NAT

CLAT Customer side translator

CORE Common Open Research Emulator

CPE Customer Premises Equipment

DCC Departamento de Ciência da Computação

DECSI Departamento de Computação e Sistemas

DHCP Dynamic Host Configuration Protocol

DHCPv6 Dynamic Host Configuration Protocol version 6

DNS Domain Name System

DS-Lite Dual Stack Lite

FTP File Transfer Protocol

GRE Generic Routing Encapsulation

HTTP Hypertext Transfer Protocol

IANA Internet Assigned Numbers Authority

ICANN Internet Corporation for Assigned Names and Numbers

ICEA Instituto de Ciências Exatas e Aplicadas

IHL Internet Header Length

IoT Internet of Things

IPv4 Internet Protocol version 4

IPv6 Internet Protocol version 6

ISATAP Intra-Site Automatic Tunnel Addressing Protocol

Lacnic Latin America and Caribbean Network Information Centre

LSN Large Scale NAT

LSPs Label Switch Paths

MBGP Multiprotocol BGP

MOS Mean Opinion Score

NAT Network Address Translation

NAT444 Network address translations at customer’s private network and carrier’s

Nic.br Núcleo de Informação e Coordenação do Ponto BR

NIR National Internet Registry

OSI Open Systems Interconnection

QoS Quality of Service

RAM Random Access Memory

RCTS Rede Ciência, Tecnologia e Sociedade

REDUnB Rede de Dados da UnB