Este documento oferece uma referência prática para a migração de redes locais do protocolo IPv4 para IPv6, abordando a escassez de endereços no IPv4 e os benefícios do IPv6. A pesquisa inclui análises e diretrizes para a implementação do IPv6 em redes médias e grandes, destacando diferentes métodos de coexistência como pilha dupla e tunelamento. O trabalho é voltado para administradores de rede e aborda soluções para desafios associados à migração.

1. INSTITUTO DE EDUCAÇÃO SUPERIOR DE BRASÍLIA
CURSO DE ENGENHARIA ELÉTRICA
MELHORES PRÁTICAS DE MIGRAÇÃO DE UMA REDE
IPv4 PARA IPv6
Alexandre José Camilo Gomes
Carlos Botelho da Trindade
MAIO DE 2009

2. ii
INSTITUTO DE EDUCAÇÃO SUPERIOR DE BRASÍLIA
CURSO DE ENGENHARIA ELÉTRICA
MELHORES PRÁTICAS DE MIGRAÇÃO DE UMA REDE
IPv4 PARA IPv6
Alexandre José Camilo Gomes
Carlos Botelho da Trindade
Trabalho de Graduação apresentada ao Curso
de Engenharia Elétrica com ênfase em
Telecomunicações do Instituto de Educação
Superior de Brasília como requisito parcial à
obtenção do título de Engenheiro Elétrico.
Orientador: Eduardo Wolski.
MAIO DE 2009

3. iii
Alexandre José Camilo Gomes
Carlos Botelho da Trindade
MELHORES PRÁTICAS DE MIGRAÇÃO DE UMA REDE
IPv4 PARA IPv6
Banca Examinadora:
__________________________________________________________
Prof.
__________________________________________________________
Prof.
__________________________________________________________
Prof.

4. iv
Dedico esta monografia à minha esposa Manoela e
minha filha Nathália, que abriram mão de uma
grande parcela de nosso convívio familiar e que não
mediram esforços para me apoiar; amo vocês !
aos meus pais, Eloizo e Helenice, pela fé e
confiança demonstrada, sempre investindo em mim
e no meu futuro;
ao meu amigo Saulo pelo apoio incondicional em
todas as minhas decisões tanto nas acertadas como
nas erradas;
e a todos os familiares e amigos que permitiram e
incentivaram esse passo a ser dado.
Alexandre Gomes
Agradeço e dedico à conquista de mais um passo
na vida, à minha esposa Lísian, que suportou
pacientemente minha ausência e incentivou-me a
persistir em busca do meu objetivo;
à minha mãe Eloíza que sempre esteve ao meu
lado;
ao meu saudoso Pai Carlos Luiz, que foi
fundamental para que pudesse chegar onde
cheguei;
ao meu irmão Rangel, que me apoiou nos
momentos difíceis;
aos meus amigos e companheiros, os meus
agradecimentos pela amizade e por tudo que
convivemos.
Carlos Botelho

5. v
Agradecemos ao nosso orientador Eduardo Wolski,
pela paciência, didática e principalmente pelo
compromisso de estar sempre à disposição e
presente em nossa orientação.
Alexandre Gomes e Carlos Botelho

6. vi
RESUMO
Com o crescimento de aplicações como Ponto a Ponto e vídeo-
conferência, e com a necessidade de computadores sempre conectados e
disponíveis, o novo protocolo IPv6 fará a substituição gradual do atual IPv4
que, num futuro próximo, se tornará inviável por escassez de endereços. Este
documento tem como finalidade servir de referência ao processo de migração
da tecnologia IPv4 para IPv6 de uma rede local gerenciada, de tamanho médio
ou grande, e problemas relacionados à mesma. É, portanto, um documento
para subsidiar as ações de um administrador de rede. O protocolo IPv6 não só
aumenta a quantidade de endereços como também possui diversos benefícios
sobre o IPv4, sendo esses descritos neste documento.
A abordagem adotada neste trabalho trata, especificamente, da
implantação de IPV6 em uma rede com serviços comumente utilizados,
mostrando, de forma prática e por meio de análises, a migração a partir de uma
rede IPv4.

7. vii
ABSTRACT
This document aims to be a practical migration reference to the IPv6
protocol suite and its issues. With the increase of the Internet, the growing of
P2P applications, video conferences and always-on computers, the standard
IPv4 will not support all needed addresses soon. IPv6 was designed to solve
this and other IPv4 issues as well as bringing new features.
This document shows a practical implementation in a managed local
network and its services, describing the migration from IPv4 and making the
analysis of this implementation.

8. viii
LISTA DE FIGURAS
Figura 2.1 – Retirada de campos cabeçalho IPv4 ............................................................. 7
Figura 2.2 – Cabeçalho IPv6 ............................................................................................ 8
Figura 2.3 – Utilização ilustrativa do IPSec ..................................................................... 8
Figura 2.4 – Rede com endereçamento Anycast ............................................................ 11
Figura 2.5 – Cabeçalho IPv6 e IPv4 ............................................................................... 13
Figura 2.6 – Cabeçalho de expansão IPv6 e IPv4 .......................................................... 14
Figura 2.7 – Cabeçalho de extensão IPv6....................................................................... 14
Figura 2.8 – Campos do pacote ICMPv6 ....................................................................... 15
Figura 2.10 – Exemplo de vídeo conferência ................................................................. 21
Figura 2.11 – Cabeçalho IPv4 e IPv6 - apresentação QoS ............................................. 23
Figura 2.11 – Cabeçalho AH e ESP ............................................................................... 26
Figura 3.1 – Coexistência - IPv6 e IPv4 ......................................................................... 30
Figura 3.2 – Tráfego de pacotes com a arquitetura de pilha dupla................................. 31
Figura 3.3 – Configuração Host a Host .......................................................................... 33
Figura 3.4 – Configuração Host a Roteador ................................................................... 34
Figura 3.5 – Configuração Roteador a Roteador ............................................................ 34
Figura 3.6 – Pilha Dupla IPv6 encapsulado IPv4 ........................................................... 35
Figura 3.8 – Estrutura de pacote ISATAP ...................................................................... 36
Figura 3.9 – Topologia utilizando túnel ISATAP .......................................................... 36
Figura 3.10 – Inicialização do ISATAP ......................................................................... 38
Figura 3.11 – Comunicação entre máquinas com ISATAP configurada no mesmo
segmento de rede. ........................................................................................................... 39
Figura 3.12 – Comunicação entre máquinas com ISATAP configurada em diferentes
segmentos de rede. .......................................................................................................... 39
Figura 3.13 – Comunicação entre máquinas com ISATAP – diferentes segmentos de
rede IPv6 ......................................................................................................................... 40
Figura 3.14 – Estrutura do endereço do túnel 6to4 ........................................................ 42
Figura 3.15 – Estrutura da conexão 6to4 ........................................................................ 43
Figura 3.16 – Comunicação do túnel 6to4...................................................................... 45
Figura 3.17 – Comunicação relay/roteador 6to4 com servidor IPv6 ............................. 47
Figura 3.18 – Comunicação túnel Broker....................................................................... 51
Figura 3.19 – Inicialização do túnel Broker ................................................................... 52
Figura 3.21 – Configuração Teredo ................................................................................ 57
Figura 3.22 – Conexão Teredo com NAT do tipo restrito ............................................. 60
Figura 3.23 – Logo Silver Fase I .................................................................................... 68
Figura 3.24 – Logo Gold Fase 2 ..................................................................................... 69
Figura 4.1 – Ambiente de Laboratório. .......................................................................... 72
Figura 4.2 – Cenário 0 – Rede Interna e operadora IPv4 - túnel Broker IPv6 ............... 74
Figura 4.3 – Cenário 1 – Rede Interna IPv4 e operadora IPv4 e IPv6 (dual-stack) ....... 75
Figura 4.4 – Cenário 2 – Rede Interna IPv4 e operadora IPv6 ....................................... 75
Figura 4.5 – Cenário 3 – Rede Interna IPv4 e IPv6 (dual-stack) e operadora IPv4 ....... 76
Figura 4.6 – Cenário 4 – Rede Interna e operadora IPv4 e IPv6 (dual-stack) ................ 77
Figura 4.7 – Cenário 5 – Rede Interna IPv4 e IPv6 (dual-stack) e operadora IPv6 ....... 77
Figura 4.8 – Cenário 6 – Rede Interna IPv6 e operadora IPv4 ....................................... 78
Figura 4.9– Cenário 7 – Rede Interna IPv6 e operadora IPv4 e IPv6 (dual-stack) ........ 79
Figura 4.10 – Cenário 8 – Rede Interna e operadora IPv6 ............................................. 79
Figura 4.11 – Roteador de borda ................................................................................... 82
Figura 4.12 – Configuração UDHCP ............................................................................ 85

9. ix
Figura 4.13 – Configuração Gateway6 .......................................................................... 85
Figura 4.14 – Configuração RADVd ............................................................................. 87
Figura 4.15 – Indicação do pacote RA – desabilitado ................................................... 88
Figura 4.16 – Indicação do pacote RA – habilitado ...................................................... 88
Figura 4.17 – Inicialização do túnel Broker .................................................................. 89
Figura 4.18 – Configuração da interface Eth0 – rede WAN ......................................... 89
Figura 4.19 – Configuração da interface eth1 ............................................................... 90
Figura 4.20 – Configuração da interface SIT1 .............................................................. 91
Figura 4.21 – Configuração da interface Loopback ...................................................... 91
Figura 4.22 – Teste de ping versão 6 ............................................................................. 91
Figura 4.23 – Tabela de roteamento do servidor – IPv4 ............................................... 92
Figura 4.24 – Roteamento default Eth0 ......................................................................... 92
Figura 4.25 – Roteamento – comando routel ................................................................ 92
Figura 4.26 – Arquivo de log do named ........................................................................ 94
Figura 4.27 – Campos configurados no dhcp6s ............................................................ 95
Figura 4.28 – Diretório do shorewall ............................................................................ 96
Figura 4.29 – Associação de zonas................................................................................. 96
Figura 4.30 – Configuração de tráfegos ......................................................................... 97
Figura 4.32 – Tipo de zonas ........................................................................................... 97
Figura 5.1 – Topologia – Transferência de arquivos – Cabo ......................................... 99
Figura 5.2 – Transferência de arquivo – comparação IPv4 x IPv6 – Via Cabo ........... 100
Figura 5.3 – Topologia – Transferência de arquivos - Wireless .................................. 101
Figura 5.4 – Transferência de arquivo – comparação IPv4 x IPv6 – Wireless ............ 102
Figura 5.5 – Hops para alcance do Freenet6 ................................................................ 103
Figura 5.6 – Teste de Ping – Comparação IPv4 x IPv6 – Servidor Freenet6 ............... 104
Figura 5.7 – Mapa de interligação de redes – através do mar ...................................... 105
Figura 5.8 – Teste de Ping – comparação IPv4 x IPv6 – Servidor Kame.net .............. 105
Figura 5.9 – Teste de Ping – Comparação IPv4 x IPv6 – Servidor IPv6.br ................. 106
Figura 5.10 – Tela de configuração – túneis desabilitados........................................... 107
Figura 5.11 – Topologia – Comunicação através de túnel 6to4 ................................... 108
Figura 5.13 – Sucesso no ping com site Google IPv6 – 6to4 IP válido ....................... 109
Figura 5.14 – Configuração endereço IP através de NAT – 6to4................................. 110
Figura 5.15 – Insucesso no ping com site Google IPv6 – 6to4 IP Nat ......................... 110
Figura 5.16 – Topologia – Comunicação através de túnel Teredo ............................... 111
Figura 5.17 – Configuração endereço IP através de NAT – Túnel Teredo .................. 111
Figura 5.18 – Tela de configuração – Túnel Teredo habilitado – IP NAT................... 112
Figura 5.19 – Sucesso no ping com site Google IPv6 – Túnel Teredo IP NAT.......... 112
Figura 5.20 – Tela de configuração – Túnel Teredo habilitado – IP Público............... 113
Figura 5.21 – Teste de Ping – comparação 6to4 x Teredo – servidor IPv6.google.com
...................................................................................................................................... 113
Figura 6.1 – Layout – Distribuição Zonas Lógicas ...................................................... 117
Figura 6.2 – Layout – WAN ......................................................................................... 117
Figura 6.3 – Layout – LAN .......................................................................................... 119
Figura 6.4 – Layout – firewall ...................................................................................... 123

10. x
LISTA DE TABELAS
Tabela 4.1 – Cenários para implantação de redes ................................................... 72
Tabela 4.2 – Configuração dos Ativos ...................................................................... 73

11. xi
LISTA DE ABREVIATURAS E SIGLAS
ADM Administrador de Redes
ADSL Assymmetric Digital Subscriber Line
AH Authentication Header
AP Access Point
ARP Address Resolution Protocol
ARPANET Advanced Research Projects Agency Network
BC Broker Cliente
BIND Berkeley Internet Name Domain
CPE Customer Premises Equipament or Provider Equipament
CIDR Classless Interdomain Routing
DAD Duplicate Address Detection
DDos Denial of Service
DHCP Dynamic Host Configuration Protocol
DHCPv6 Dynamic Host Configuration Protocol version 6
DNS Domain Name System
DNSv6 Domain Name System version 6
DSTM Dual Stack Transition Mechanism
ESP Encapsulation Security Payload Header
HTML HyperText Markup Language
IAB Internet Association Board
IANA Assingned Numbers Autority
ICMP Internet Control Message Protocol
ICMPv6 Internet Control Message Protocol version 6
IDD Interface Identifier
IESG Internet Enginnering Steering Group
IETF Internet Engineering Task Force
IKE Internet Key Exchange
IPAE IP Address Encapsulation
IPng IP The Next Generation
IP Internet Protocol
IPv4 Internet Protocol Version 4

12. xii
IPv6 Internet Protocol Version 6
ISC Internet Systems Consortuim
LAN Local Area Network
MIPv6 Mobile Internet Protocol Version 6
MLD Multicast Listener Discovery
MTU Maximum Transmit Unit
MSDP Multicast Source Discovery Protocol
NAT Network Address Translation
ND Neighbor Discovery
NGTrans Next Generation Transition
OP Operadora de Telecom
OSPF Open Shortest Path First
OSPFv3 Open Shortest Path First version 3
P2P Peer to peer
PAA PANA Authentication Agent
PANA Protocol for Autentication and Network Access
PDA Personal digital assistants
PIM Protocol Independent Multicast
PKI Public Key Infrastructure
QoS Quality fo Services
RA Router Advertisement
RIPng Routing Information Protocol next generation
ROAD Routing and Addressing
RS Router Solicitation
SIP Simple Internet Protocol
SSM Source Specific Multicast
TB Tunnel Broker
TCP Transmission Control Protocol
TI Tecnologia da Informação
TS Tunnel Server
TTL Time to Live
UDP User Datagram Protocol

13. xiii
SUMÁRIO
1. INTRODUÇÃO ........................................................................................................................ 1
2. FUNDAMENTAÇÃO TEÓRICA ................................................................................................. 4
2.1 Sobre o IPv6............................................................................................................................. 4
2.1.1 Histórico da Evolução do Protocolo IPv6 .................................................................. 4
2.1.2 Instituições Ligadas ao IPv6.............................................................................................. 5
2.1.2.1 IETF ............................................................................................................................ 5
2.1.2.2 NGtrans ..................................................................................................................... 6
2.1.2.3 6Bone ........................................................................................................................ 6
2.2 Características do Protocolo IPv6 2.2.1 Concepção do IPv6................................................... 7
2.2.2 Endereçamento no IPv6 ................................................................................................... 9
2.2.2.1 Formação do Endereço ............................................................................................. 9
2.2.2.2 Endereçamento Unicast .......................................................................................... 11
2.2.2.3 Endereçamento Anycast ......................................................................................... 11
2.2.2.4 Endereçamento Multicast ....................................................................................... 12
2.2.3 Cabeçalho IPv6 ............................................................................................................... 12
2.2.4 Serviços Básicos do IPv6 2.2.4.1 ICMPv6....................................................................... 15
2.2.4.2 Neighbor Discovery ................................................................................................. 16
2.2.4.3 Autoconfiguração: ................................................................................................... 17
2.2.4.4 DHCPv6 .................................................................................................................... 18
2.2.4.5 DNSv6 ...................................................................................................................... 20
2.2.4.6 Multicasting............................................................................................................. 21
2.2.4.7 QoS .......................................................................................................................... 22
2.2.5 Segurança no IPv6 ...................................................................................................... 23
2.2.5.1 Ameaça I – Procura de Gateways ........................................................................... 23
2.2.5.2 Ameaça II – Procura de Endereços Multicast......................................................... 24
2.2.5.3 Ameaça III – Acesso não Autorizado ...................................................................... 24
2.2.5.4 Ameaça IV – Pontos Fracos nos Firewalls .............................................................. 25
2.2.5.5 Ameaça V – Ataques Através de Cabeçalhos .......................................................... 25
2.2.5.6 Ameaça VI – Pontos Fracos do Protocolo ............................................................... 26
2.2.5.7 Ameaça VII – Ataques de DDoS ............................................................................... 26
3. PROCESSOS DE UMA MIGRAÇÃO – COEXISTÊNCIA IPv4/IPv6 E SUPORTE ......................... 28
3.1 Premissas............................................................................................................................... 28

14. xiv
3.2 Mecanismos de coexistência e suas falhas ........................................................................... 29
3.2.1 Pilha dupla (dual-stack) .................................................................................................. 31
3.2.1.1 Segurança em dual-stack (Pilha Dupla) ................................................................... 32
3.2.2 Tunelamento .................................................................................................................. 32
3.2.2.1 Túneis ISATAP .......................................................................................................... 36
3.2.2.1.1 Modelo de comunicação ISAPTAP ....................................................................... 37
3.2.2.1.2 Segurança de Túnel ISATAP.................................................................................. 41
3.2.2.2 Túnel 6to4 ............................................................................................................... 42
3.2.2.2.1 Comunicação Cliente 6to4/Roteador 6to4 com Servidor IPv6 Nativo................. 46
3.2.2.2.2 Segurança e Limitações do Túnel 6to4 ................................................................ 49
3.2.2.3 Túnel Broker ............................................................................................................ 50
3.2.2.3.1 Segurança Túnel Broker ....................................................................................... 53
3.2.2.4 Túnel Teredo .......................................................................................................... 55
3.2.2.4.1 Segurança do túnel Teredo .................................................................................. 61
3.2.2.4.2 Problemas com Túneis: ........................................................................................ 62
3.3.3 Tradução......................................................................................................................... 63
3.3.3.1 Mecanismos de Tradução ....................................................................................... 64
3.3.3.1.1 Staless IP/ICMP Translation( SIIT) ........................................................................ 64
3.3.3.1.2 Network Address Translation with Protocol Translation (NAT/NAPT-PT)............ 64
3.3.3.1.3 Network Address Port Translation and Packet Translation (NAPT-PT) ................ 65
3.3.4 Problemas Adicionais de Segurança em IPv6................................................................. 65
3.3.4.1 Roteamento............................................................................................................. 65
3.3.4.2 Router Advertisement e do Neighbor Discorvery .................................................... 65
3.3.4.3 DHCPv6 .................................................................................................................... 66
3.3.5 Compatibilidade de Software, Sistemas Operacionais e Hardwares (Firmwares) ......... 67
3.3.5.1 Fase 1 - Silver Logo .................................................................................................. 68
3.3.5.2 Fase 2 - Gold Logo .................................................................................................. 69
4. CONFIGURAÇÕES DO AMBIENTE DE TESTE ........................................................................ 71
4.1 Cenários................................................................................................................................. 71
Tabela 4.1 – Cenários para implantação de redes .................................................................. 72
Tabela 4.2 – Configuração dos ativos...................................................................................... 73
4.1.1 - Cenário 0 ...................................................................................................................... 73
4.1.2 - Cenário 1 ...................................................................................................................... 74
4.1.3 - Cenário 2 ...................................................................................................................... 75

15. xv
4.1.4 - Cenário 3 ...................................................................................................................... 75
4.1.5 - Cenário 4 ...................................................................................................................... 76
4.1.6 - Cenário 5 ...................................................................................................................... 77
4.1.7 - Cenário 6 ...................................................................................................................... 78
4.1.8 - Cenário 7 ...................................................................................................................... 78
4.1.9 - Cenário 8 ...................................................................................................................... 79
4.2 Configurações Realizadas ...................................................................................................... 80
4.2.1 Roteador de Borda ......................................................................................................... 80
4.2.1.1 Sistema Operacional utilizado e sua distribuição ................................................... 80
4.2.1.2 Configuração do Roteador de Borda....................................................................... 81
4.2.1.2 Sincronia da árvore do Portage # emerge –sync ................................................... 83
4.2.1.3 Programas Instalados .............................................................................................. 84
4.2.1.3.1 Kernel ................................................................................................................... 84
4.2.1.3.2 DHCPv4 ................................................................................................................. 84
4.2.1.3.3 Router Advertisement Daemon ............................................................................ 85
4.2.1.3.4 Túnel Broker (freenet6) ........................................................................................ 86
4.2.1.3.5 DNS (BIND9) ......................................................................................................... 93
4.2.1.3.6 DHCPv6 ................................................................................................................. 94
4.2.1.3.7 Shorewall .............................................................................................................. 95
4.2.1.3.7.1 Arquivo Interfaces ............................................................................................. 96
4.2.1.3.7.2 Arquivo policy.................................................................................................... 96
4.2.1.3.7.3 Arquivo masq .................................................................................................... 97
4.2.1.3.7.4 Arquivo zones ................................................................................................... 97
4.2.1.3.7.5 Arquivo shorewall.conf .................................................................................... 98
4.2.1.3.7.6 Firewall (IPtables) ............................................................................................. 98
5. TESTES E ANÁLISE DE RESULTADOS .................................................................................... 99
5.1 Teste Rede Local ( Sem utilização de Túnel) ......................................................................... 99
5.2 Teste utilizando Mecanismos de Tunelamento .................................................................. 102
5.2.1 Túnel Broker ................................................................................................................. 102
5.2.2 Túnel 6to4 .................................................................................................................... 107
5.2.3 Túnel Teredo ................................................................................................................ 110
6. MELHORES PRÁTICAS PARA MIGRAÇÃO ........................................................................... 116
6.1 WAN ( Roteador de borda IPv6) .......................................................................................... 117
6.1.1 Criar conta no túnel Broker ................................................................................... 118

16. xvi
6.1.2 Implantar roteador de borda do túnel .................................................................. 118
6.1.3 Configurar o serviço de RA com o prefixo recebido pelo Broker .......................... 119
6.2 LAN ( Exceto firewall) .......................................................................................................... 119
6.2.1 Geral ...................................................................................................................... 119
6.2.1.1 Levantar firmwares e softwares em produção mapeando os que possuem suporte
somente à IPv4 .................................................................................................................. 120
6.2.1.2 Dividir firmware e software que possuem suporte em duas fases do IPv6 Ready
(Fase 1 e Fase 2) ................................................................................................................ 120
6.2.1.3 Atualizar os SO's e firmwares que possuírem atualização de suporte ao IPv6..... 120
6.2.1.4 Habilitar a pilha-dupla (IPv6/IPv4) e DHCPv6 nos hosts ....................................... 120
6.2.1.5 Verificar atualizações de versionamento e segurança referente ao IPv6............. 121
6.2.2 Específicos ............................................................................................................. 121
6.2.2.1 Servidores 6.2.2.1.1 DHCPv6 6.2.2.1.1.1 Implantar o serviço DHCPv6 e habilitar o
IPv6 na interface de rede .................................................................................................. 121
6.2.2.1.1.2 Inserir o(s) endereço(s) de escopo link-local do DNS nos pacotes do DHCPv6
........................................................................................................................................... 122
6.2.2.1.2 DNSv6 6.2.2.1.2.1 Habilitar DNS para suportar IPv6 e habilitar o IPv6 em sua
interface de rede ............................................................................................................... 122
6.2.2.1.2.2 Configurar as zonas Internas para o IPv6 ....................................................... 122
6.2.2.1.2.3 Habilitar endereços na interface IPv6 fec0:0:0:ffff::1 a ::3 (Site-Local) para uso
de equipamentos IPv6 Ready Fase 1................................................................................. 122
6.2 Firewall ................................................................................................................................ 123
6.2.1 Habilitar o IPv6 nas interfaces de rede ................................................................. 123
6.2.2 Habilitar o roteamento IPv6 e bloquear seu tráfego ............................................ 123
6.2.3 Criar regras no firewall .......................................................................................... 124
6.2.3.1 IPv4 ........................................................................................................................ 124
6.2.3.1.1 Bloquear o protocolo 41 e portas UDP 3544 .................................................... 124
6.2.3.2 IPv6 ....................................................................................................................... 124
6.2.3.2.1 Liberar as portas dos serviços a serem utilizados (basear nos serviços IPv4) ... 124
6.2.3.2.2 Filtrar o tráfego de tipos ICMPv6 que não são essenciais................................. 124
6.2.3.2.3 Permitir o tráfego de pacote RA para LAN provenientes do roteador de borda
(Túnel IPv6), sentido “1” (Figura 6.1) ................................................................................ 125
7. CONCLUSÃO ...................................................................................................................... 127
BIBLIOGRAFIA ............................................................................................................................ 129
APÊNDICE A ............................................................................................................................... 133
A.1 - Configuração do Kernel ( parte referente ao IPv6)....................................................... 133

17. xvii
A.2 - Configuração do BIND ................................................................................................... 139
A.3 - Configuração do Broker ................................................................................................ 141
A.4 - Configuração do Shorewall ........................................................................................... 146
A.5 - Configuração do UDHCPd ............................................................................................. 148
A.6 - Configuração do DHCP6s .............................................................................................. 148
APÊNDICE B ............................................................................................................................... 148
B.1 - Lista de Verificação ....................................................................................................... 149
B.2 - Fluxograma.................................................................................................................... 150

18. 1
1. INTRODUÇÃO
Em 1969, a ARPANET foi criada com a intenção de interligar centros de
pesquisa nos Estados Unidos e foi o grande marco para o avanço das redes de
telecomunicações, culminando na criação do que hoje é conhecido como
Internet e na utilização extensiva do IPv4. O IPv4 suportou a interligação entre
redes em nível global, tendo a Internet atingido à dimensão que hoje se
conhece. Devido ao recente crescimento exponencial da Internet e seus
usuários e equipamentos “on-line” e do surgimento da Web2.0, o IPv4 não será
mais capaz de suprir esse potencial aumento do número de utilizadores ou das
necessidades geográficas da expansão da Internet. Segundo a Internet
Assigned Numbers Authority (IANA), restam cerca de 11% de endereços IPv4
disponíveis no mundo (fonte: http://www.inetcore.com/project/IPv4ec/
index_pt.html).
O tempo de vida do IPv4 vem se estendendo pelo uso de técnicas
paliativas para a reutilização de endereços, tais como o Network Address
Translation (NAT), Classless Interdomain Routing (CIDR), e atribuições de
endereços de forma temporária com o serviço Dynamic Host Configuration
Protocol (DHCP). Essas técnicas surgiram para aumentar o espaço de
endereçamento e satisfazer o tradicional modelo cliente/servidor, mas não
cumprem os requisitos da verdadeira mobilidade entre rede e utilizador, assim
como o novo modelo emergente de serviços voltados ao Peer to Peer (P2P),
onde todos passam a ser clientes e servidores em determinado nível de
serviço. Às aplicações têm sido fornecidas maiores larguras de banda, e delas
é demandada melhor desempenho. A necessidade de ambientes sempre
disponíveis proíbe estas técnicas de conversão e de alocação temporária de
endereços IP, feitas hoje pelo DHCP. Além disso, o “plug and play” requerido
pelas aplicações aumentam, significativamente, o requisito do protocolo, de
forma a facilitar a utilização dos equipamentos. Milhões de novos dispositivos
tecnológicos não serão capazes de obter endereços IPv4 globais, e isso é
inapropriado para os novos serviços emergentes. O IPv4 chegará, brevemente,
à fase em que tem de ser feita a escolha entre novas capacidades ou uma rede

19. 2
maior, mas não as duas. Por outras palavras, faz-se necessário um novo
protocolo para fornecer características novas e melhoradas, além de resolver o
problema da escassez de endereços IP. Esse novo protocolo é o IPv6.
O IP versão 6, ou na sua forma abreviada IPv6, é a nova versão do
protocolo de Internet para substituir o atual IPv4. Apesar da escassez do
espaço de endereçamento IPv4 ter sido a razão principal para o
desenvolvimento de um novo protocolo, os arquitetos do IPv6 adicionaram
novas características em um conjunto de aperfeiçoamentos críticos do IPv4.
Neste trabalho serão apresentados os vários aspectos do protocolo, incluindo
endereçamento, autoconfiguração e coexistência entre IPv4 e IPv6.
Considerando o cenário apresentado, este trabalho tem como escopo a
elaboração e verificação, por meio de estudo, observação, implantação e
testes, de regras de melhores práticas para uma migração de uma rede IPv4
para uma rede mista (IPv4/IPv6) e, futuramente, IPv6 pura, minimizando os
impactos e falhas de segurança, considerando os serviços mais comumente
usados em uma rede, assim como a interação com equipamentos legados IPv4
puros.
O objetivo geral do trabalho é, portanto, elaborar e verificar regras de
melhores práticas na migração de uma rede IPv4 para IPv6, tanto na questão
executiva, quanto na questão de segurança, considerando que será necessário
que se tenha um ambiente de convivência entre as duas versões do protocolo.
Os objetivos específicos são os seguintes:
• Estudar a arquitetura do IPv6 e suas diferenças em relação ao IPv4;
• Estudar as formas de interação de coexistência entre as duas
tecnologias;
• Estudar quais são os serviços que sofrem alterações com a migração;

20. 3
• Implementar, em laboratório, os serviços que interagem, diretamente,
com endereçamento da camada de rede: DNS, DHCP;
• Avaliar o impacto da migração na segurança da rede;
• Avaliar o impacto da migração no desempenho da rede;
• Levantar requisitos importantes para as mudanças em um projeto de
migração;
• Elaborar um documento para auxiliar uma migração de forma estável e
segura, tendo como público-alvo os administradores de redes.
Nos próximos capítulos, será apresentado um histórico da evolução do
protocolo IPv6, comparando com o protocolo IPv4, de utilização atual,
demonstrando as características do novo protocolo, como a nova formação do
endereçamento, mudança do cabeçalho, dos serviços básicos, aumento da
segurança e a coexistência entre os dois protocolos. Serão vistos, também, os
processos de uma migração, mecanismos de interoperação e tradução,
desempenho e problemas conhecidos da migração, configurações realizadas
no laboratório, realização de testes e, por fim, as melhores práticas para que a
migração seja feita de forma estável, segura e eficiente.

21. 4
2. FUNDAMENTAÇÃO TEÓRICA
Serão apresentados, neste capítulo, a evolução do protocolo IPv6, as
instituições responsáveis pela introdução do novo protocolo e as principais
características, desde a sua concepção, nova forma de endereçamento,
alteração na forma de comunicação dos serviços e os recursos de segurança.
2.1 Sobre o IPv6
2.1.1 Histórico da Evolução do Protocolo IPv6
Segundo o IPv6.org “O projeto IP the Next Generation (IPng) - representa o
resultado da evolução de diferentes propostas da Internet Engineering Task
Force (IETF), bem como o esforço conjunto de vários grupos de trabalho.
Conforme aponta a RFC 1752 (BRANDER & MANKIN, 1995), o projeto IPng
sofreu a seguinte evolução:
a. 1990 - No encontro Internet Engineering Task Torce (IETF) de
Vancouver, Frank Solensky, Phill Gross e Sue Hares afirmaram que à
taxa de atribuição do espaço de endereçamento IPv4, existente à época,
as classes do tipo B estariam esgotadas, possivelmente, por volta de
Março de 1994.
b. 1991 - A IETF forma o grupo de trabalho Routing and Addressing
(ROAD), no encontro de Santa Fé, com o objetivo de encontrar uma
solução para a exaustão do espaço de endereçamento IPv4.
c. 1992 - A Internet Association Board (IAB) apresenta o documento IP
version 7, paralelamente aos esforços do grupo de trabalho ROAD, em
que recomenda à IETF a preparação de um plano detalhado para o
sucessor do protocolo IP. A IETF rejeita esta sugestão e apresenta
pedido de propostas recomendadas pelo grupo ROAD. Como resposta a

22. 5
este pedido surgiram algumas propostas: IP Encaps, Nimrod e Simple
CLNP.
No mesmo ano surgem mais três propostas: - The P Internet Protocol
(PIP), The Simple Internet Protocol (SIP).
d. 1993 – Phil Gross do Internet Engineering Steering Group (IESG)
apresenta um memorando intitulado "A Direction for IPng", onde anuncia
a criação de uma área temporária para o IPng. CLNP e IP Encaps
evoluem, dando origem, respectivamente, ao TCP e ao UDP, TUBA e
IPAE. Neste mesmo ano, o SIP evoluiu, abrangendo características do
IP Address Encapsulation IPAE. O IPAE foi adotado como estratégia de
transição para o SIP, proposto por Steve Deering em Novembro de
1992. O SIP aumentava o endereço IP para 64 bits, tornava a
fragmentação de pacotes opcional e eliminava vários aspectos obsoletos
do IP.
g. Em 1994, a comissão do IPng revisou todas as propostas; SIP e PIP
deram origem à proposta The Simple Internet Protocol Plus (SIPP) e
publicou-se sua recomendação sugerindo o SIPP como a base para o
novo protocolo IP, mas com mudanças em algumas características
chaves da especificação original. Particularmente, o novo protocolo teria
128 bits e se chamaria IPv6. Ocorreu, então, a aprovação do documento
The Recommendation for the IP Next Generation Protocol como norma
oficial de desenvolvimento do IPng.
A primeira conexão com o protocolo IPv6 foi estabelecida em março de
1998 com a Cisco System, nos EUA.”
2.1.2 Instituições Ligadas ao IPv6
2.1.2.1 IETF
O IETF é uma sociedade internacional, composta de técnicos, agências,
fabricantes de equipamentos, fornecedores e pesquisadores, preocupados com

23. 6
a evolução da arquitetura da Internet e seu perfeito funcionamento. O IETF tem
como missão identificar e propor soluções e problemas relacionados à
utilização da Internet, além de propor padronização das tecnologias e
protocolos envolvidos.
2.1.2.2 NGtrans
O IPng Transition (NGTrans) é um grupo de trabalho da IETF que
estuda e define procedimento para a transição do IPv4 para o IPv6. Sua
estratégia é baseada em:
• Produzir um documento detalhando a infra-estrutura, como será e
o que será necessário para a transição;
• Definir e especificar os mecanismos obrigatórios e opcionais a
serem implementados pelos fabricantes nos hosts, roteadores e
outros equipamentos de rede, a fim de suportar o período de
transição;
• Articular um plano operacional concreto, quando da transição
entre o IPv4 e o IPv6.
2.1.2.3 6Bone
O 6Bone, Backbone IPv6 coordenado pelo NGTrans, foi um teste de
campo para auxiliar na evolução, no desenvolvimento e no aperfeiçoamento do
protocolo IPng, tendo integrado vários países.
Operacional desde 1996, este Backbone é implementado através de uma
rede virtual sobre a rede física IPv4 da atual Internet. A rede virtual é composta
de redes locais IPv6 ligadas entre si por túneis ponto-a-ponto IPv6 sobre IPv4.
Os túneis são realizados por roteadores com pilha dupla (IPv6 e IPv4) com
suporte para roteamento estático e dinâmico e as redes locais IPv6 são
compostas por estações com sistemas operacionais com suporte a IPv6 e
IPv4.

24. 7
2.2 Características do Protocolo IPv6
2.2.1 Concepção do IPv6
O IPv6 foi concebido para satisfazer aos requisitos da potencial
expansão da Internet e irá permitir uma comunicação global, onde as regras de
endereçamentos serão novamente transparentes para as aplicações, como
feitas anteriormente ao uso do NAT, através da autoconfiguração e do suporte
plug and play, os dispositivos de rede conseguirão ligar-se à rede sem
configuração manual. O IPv6 consegue propiciar isso através dos seguintes
benefícios às redes e aos profissionais de TI:
• Primeiramente, o IPv6 possui bastante espaço para endereços,
permitindo uma disponibilidade e escalabilidade globais. Isso
resultará em um número quase que ilimitado de endereços IP e
numa arquitetura hierárquica de rede para um encaminhamento
eficiente dos dados; isso elimina os problemas associados ao NAT
como, por exemplo, a dificuldade de se abrir a porta de um serviço
que está atrás do NAT. A capacidade de fornecer endereços globais
para cada dispositivo de rede permite uma escalabilidade “fim-a-fim”;
conseqüentemente, a gestão da rede será mais simples e fácil.
• Segundo; um formato simplificado do cabeçalho para uma
manipulação eficiente dos pacotes. No IPv6, seis dos doze campos
do cabeçalho IPv4 foram retirados (campos em verde claro);
Figura 2.1 – Retirada de campos cabeçalho IPv4

25. 8
Alguns campos continuam a existir, mas com nomenclatura diferentes
(campos em vermelho); e também foi adicionado um novo campo
(campo em laranja) para aumentar a eficiência e introduzir novas
funcionalidades;
Figura 2.2 – Cabeçalho IPv6
• Em terceiro lugar; uma arquitetura de redes hierárquica para um
encaminhamento eficiente que segue alguns princípios do CIDR no
IPv4. Outra vantagem importante do IPv6 é a segurança incorporada
com a implementação mandatória do IP Security Protocol (IPSec),
diferentemente do IPv4, em que a utilização do IPSec é opcional e
teve que ser adaptada para o funcionamento. O IPSec faz parte
intrínseca do protocolo e, por isto, sua habilitação na rede as tornam
potencialmente mais seguras;
Figura 2.3 – Utilização ilustrativa do IPSec

26. 9
Adicionalmente, o IPv6 oferece um número crescente de endereços
multicast e não utilizará o broadcast, diminuindo assim o tráfego. Também no
IPv6, o protocolo Internet Control Message Protocol (ICMP) foi revisto,
tornando-se mais eficaz, e incluindo novas funcionalidades para suportar a
autoconfiguração, multicast, varredura e descobrimento de vizinhança (antes
realizado por broadcasts na rede). E, finalmente, o IPv6 oferece mobilidade
integrada, uma vez que o surgimento esperado de serviços de dados em redes
sem fio será um impulsionador chave do IPv6.
2.2.2 Endereçamento no IPv6
2.2.2.1 Formação do Endereço
Em seguida, é feita a apresentação da sintaxe do endereçamento
utilizado pelo IPv6, incluindo o prefixo e, também, são mostrados os diferentes
tipos de endereços e como os hosts podem, automaticamente, montar seu
próprio endereço a partir de seu endereço físico - MAC Adresss.
O formato do endereçamento IP muda, drasticamente, da versão 4 para
a versão 6. Em vez de 32 bits do endereço IPv4, um endereço IPv6 possui 128
bits. Considerando a população atual da terra, resultaria em pelo menos 1000
endereços por pessoa. Embora seja uma quantidade exagerada para as
necessidades atuais, ele elimina qualquer possibilidade de escassez de
endereços IP. (HAGEN, 2002)
Os endereços em IPv6 são escritos no seguinte formato:
XXXX:XXXX:XXXX:XXXX:XXXX:XXXX:XXXX:XXXX
Sendo que cada grupo de quatro “X” representa um campo de 16 bits
em hexadecimal e, diferentemente do IPv4, os separadores no IPv6 são “:”,
sendo anteriormente representados por “.”. Os números em hexadecimal não
são sensíveis a letras maiúsculas ou minúsculas. Sendo assim, o endereço
escrito como no exemplo:
2001:0000:1234:0000:0000:C1C0:ABCD:0876

27. 10
Pode ser representado como o endereço:
2001:0000:1234:0000:0000:c1c0:abcd:0876
Adicionalmente, os zeros não significativos em um campo podem ser
comprimidos e o endereço acima poderá ser escrito da seguinte forma:
2001:0:1234:0:0:C1C0:ABCD:0876
O IPv6 também utiliza uma outra importante convenção para abreviar os
endereços, fazendo com que seqüências sucessivas de “0” sejam
representados por “::”, de forma a acontecer, nessa representação, somente
uma vez o artifício e, dessa forma, o endereço acima se tornaria:
2001:0:1234::C1C0:ABCD:0876
Porém, não poderia se tornar:
2001::1234::C1C0:ABCD:0876
Pois, o artifício estaria sendo utilizado mais de uma vez.
Um endereço IPv6 pode ser expresso no seguinte formato IPv6 address
/ prefix length da mesma forma que um endereço IPv4 é representado na
notação CIDR. Por exemplo: 1080:6809:8086:6502/64 é um prefixo IPv6
completamente válido e corresponderia ao endereço 1080:6809:8086:6502:: ou
seja representando o resto dos zeros do endereço. O valor “/64” é um decimal
que representa o número de bits que ficam à esquerda e que representam o
prefixo. Um prefixo IPv6 também pode caracterizar um grupo de endereços
como os utilizados para identificar redes como, por exemplo, um segmento, um
conjunto de LAN’s ou até mesmo uma rede de uma operadora.
Um segmento de rede, usualmente, possui um prefixo de 64 bits,
enquanto que um conjunto de redes locais tem normalmente um prefixo de 48
bits e, no último caso, os 16 bits estão alocados livremente como um ID de sub-
rede, para se poder segmentar uma rede da mesma forma de como é feita no
IPv4.

28. 11
Existe uma diferença importante entre um endereço de um host IPv4
para um host IPv6. Um host IPv4 tem, normalmente, um endereço IP, mas um
host IPv6 possui geralmente mais do que um endereço IP.
Existem três tipos principais de endereços IPv6: o unicast, o anycast e o
multicast.
2.2.2.2 Endereçamento Unicast
O endereço unicast identifica um único host da rede, e qualquer pacote
endereçado a este endereço unicast é entregue na interface do host que o
possui. Os 64 últimos bits, os menos significativos possuem o nome de
Interface Identifier (IID). Os endereços unicast podem ser divididos em quatro
tipos: endereços unicast globais; endereços locais únicos ou ULA’s; endereços
unicast Link-local e, finalmente, endereços IPv6 com mapeamento IPv4.
(Hinden & Haberman, 2005). Maiores informações sobre os endereços unicast,
podem ser obtidas através da RFC 4193.
2.2.2.3 Endereçamento Anycast
Um endereço anycast identifica um conjunto de interfaces, mas que
pertencem a hosts diferentes. Como na figura abaixo:
Figura 2.4 – Rede com endereçamento Anycast

29. 12
Um pacote enviado para um endereço anycast só é entregue à interface
do host mais próximo identificado pelo endereço anycast. A interface mais
próxima é determinada pelos protocolos de encaminhamento em utilização.
Isso permite que um host passe pelo caminho mais curto quando procura um
servidor Domain Name System (DNS).
2.2.2.4 Endereçamento Multicast
Um endereço multicast é um identificador para um “conjunto” de
interfaces, que pertencem a hosts diferentes. Mas, diferentemente do anycast,
os pacotes são entregues a todos os hosts que subscreveram esse endereço
de multicast. É replicado em todo caminho entre o host emissor e os múltiplos
receptores. Endereços multicast possuem prefixo FF00::/8 obrigatoriamente.
O IPv6 não utiliza broadcast, que, no caso do IPv4, a utilização diminui
em o desempenho da rede, uma vez que todos os hosts têm de processar
todos os broadcasts deste mesmo segmento. Sendo que a maior parte dos
broadcasts não é aproveitada pela a maioria dos hosts. O problema fica cada
vez maior, quanto maior o tamanho de um determinado segmento da rede. A
solução dada pelo IPv6 para o problema do broadcast é a implementação do
endereço Multicast “all-nodes-on-link” que possui o seguinte formato: FF02::1.
Este endereço Multicast é utilizado para substituir broadcasts essenciais
e, em outros casos, são utilizadas mensagens Multicast mais limitadas.
2.2.3 Cabeçalho IPv6
O cabeçalho IPv6 é mais simples e eficiente que o cabeçalho IPv4,
simplesmente pelo fato de ter um comprimento de tamanho fixo e um número
inferior de campos como mostrado na figura abaixo:

30. 13
Figura 2.5 – Cabeçalho IPv6 e IPv4
Essa característica permite ao IPv6 ter um encaminhamento mais eficaz,
com maior desempenho e escalabilidade.
O campo “Version” continua a existir e tem que ter o valor igual a “6”
para indicar que é um pacote IPv6.
Os campos “Source Address” e “Destination Address” são mantidos,
mas com o detalhe que ambos os campos possuem 128 bits para suportar o
endereçamento IPv6. Diferentemente do IPv6, no IPv4 os campos opcionais
faziam parte do cabeçalho, sendo que no IPv6 foram substituídos por uma
cadeia de cabeçalhos de extensão, opcional posicionados logo depois do
cabeçalho IPv6. Os cabeçalhos de extensão IPv6 permitem que sejam
implementadas opções sem diminuir o desempenho, uma vez que já não é
necessário que todos os roteadores o processem.
Em comparação com o IPv4 foram retirados cinco campos de
cabeçalho, sendo eles: o “Header Checksum”, tendo em vista que a qualidade
dos links hoje é muito superior a antigamente, em relação à quantidade de
erros e à velocidade na transmissão, além do que as verificações de
integridade já são efetuadas em camadas superiores e inferiores à camada IP.
O Campo “Header Length” foi removido já que, no IPv6, o tamanho do
cabeçalho é fixo. No IPv6 foram também retirados os três campos relacionados
à fragmentação de dados do IPv4: os campos “Identification”, “Flags” e
“Fragment offset”. Sendo assim, a fragmentação pode ser feita utilizando a
extensão apropriada. Foram também modificados e atribuídos novos nomes

31. 14
para quatro campo do cabeçalho IPv4; o campo “type of service” foi substituído
por “Trafic Class”; o campo “Protocol Type” pelo campo “Next Header”; o
campo “Total Length” pelo campo “Payload Lenth” e o campo “Time to Live”
substituído pelo campo “Hop Limit” no IPv6. E, finalmente, foi adicionado um
campo denominado “Flow Label”, fazendo com que um cabeçalho IPv4 com
treze campos se torna um IPv6 de oito campos com quarenta octetos fixos.
Ao contrário do IPv4, que define opções para o cabeçalho, no IPv6 as
opções são abrangidas por cabeçalhos de extensão, sendo que estes podem
ser inseridos quando necessários e, se possível, omitidos como mostrado na
figura abaixo:
Figura 2.6 – Cabeçalho de expansão IPv6 e IPv4
Caso exista, cada cabeçalho de extensão é alinhado a 64 bits, pois, em
um pacote IPv6, não existe um número fixo de cabeçalhos de extensão; por
isso a denominação de “cadeia de cabeçalhos”. O campo “Next Header” do
cabeçalho anterior identifica o cabeçalho de extensão e, sendo assim, o último
cabeçalho de extensão possui no campo “Next Header” um nome de um
protocolo de camada de transporte, como TCP ou UDP:
Figura 2.7 – Cabeçalho de extensão IPv6
Os cabeçalhos de extensão IPv6 estão ligados em série e, quando no
mesmo pacote, são utilizados múltiplos cabeçalhos de extensão. Os mesmos

32. 15
devem seguir a seguinte ordem: primeiro, o cabeçalho “Hop-by-Hop Options”,
depois o cabeçalho “Destination Options”, seguido pelo cabeçalho “Routing”, o
cabeçalho “Fragment”, o cabeçalho “Authentication”, depois o cabeçalho
“Encapsulation Security Payload” e por último o cabeçalho “Upper-Layer”.
Como alternativa, o cabeçalho “Destination Options” pode ser posicionado após
o cabeçalho “Authentication”. Na transmissão dos pacotes, o host de origem
deve manter esta ordem para a montagem dos cabeçalhos, mas os hosts de
destino devem estar preparados para receber em qualquer ordem.
Adicionalmente, é utilizado um cabeçalho “Mobility” pelos hosts que forem
implementar mobilidade em IPv6 ou MIPv6. (BRADNER,1996).
2.2.4 Serviços Básicos do IPv6
2.2.4.1 ICMPv6
Os hosts IP necessitam de um protocolo específico para a transferência
de mensagens relacionadas com os pressupostos IP’s de outros hosts. Este
protocolo é denominado Internet Control Message Protocol (ICMP), sendo
utilizado para reportar situações de falha, informações e funções de
diagnóstico. Através da geração de relatórios de erros e de mensagens de
informação, o ICMP no IPv6 funciona, basicamente, da mesma forma que o
ICMP no IPv4, mas, adicionalmente, os pacotes IPv6 são utilizados no
processo de “Neighbor Discovery”, “path MTU Discovery” e no “Multicast
Listener Discovery”. O cabeçalho ICMPv6 é identificado por um “Next Header”
com um valor de 58. A figura abaixo mostra os campos de um pacote ICMPv6:
Figura 2.8 – Campos do pacote ICMPv6

33. 16
Nos pacotes ICMPv6, o campo “Type” indica o tipo de mensagem e o
campo “Code” fornece mais informações para mensagens específicas. O valor
do campo “Checksum” é construído, tendo por base os campos do pacote
ICMPv6 e do cabeçalho IPv6. Já o campo “Message Body” do ICMPv6 contém
informações de erro ou de diagnóstico, relevantes para o processamento de
pacote IP. Tal como o ICMPv4, o ICMPv6 é, muitas vezes, bloqueado por
políticas de seguranças implementadas nos “firewalls” devido a ataques
baseados em ICMP. O campo “Type” do cabeçalho define o tipo de mensagem,
nomeadamente: “destination unreachable”, “packet too big”, “time exceeded”,
“parameter problem”, “echo request” e “echo reply”.
2.2.4.2 Neighbor Discovery
O Protocolo “Neighbor Discovery” do IPv6 utiliza mensagens ICMPv6 e
assemelha-se a uma junção melhorada dos protocolos ARP, ICMP Router
Discover e ICMP Redirect do IPv4. No IPv6 os hosts, sejam eles hosts ou
roteadores, utilizam o Neighbor Discovery para determinar o endereço de
camada 2 dos vizinhos que se encontram no mesmo segmento de rede e para,
rapidamente, apagarem os endereços armazenados que se tornaram inválidos.
Os hosts utilizam também do Neighbor Discovery para encontrar roteadores
vizinhos dispostos a reencaminhar os seus pacotes. Finalmente, os hosts
utilizam o protocolo para manter um registro atualizado dos vizinhos que
podem, ou não, ser acessados, e para detectarem alterações nos endereços
da camada de enlace. O Neighbor Discovery resolve um conjunto de
problemas relacionados à interação de hosts associados ao mesmo segmento
de rede, definindo mecanismos para solucionar esse conjunto: (RFC2461,
1998)
• Router Discovery: Processo utilizado para que os hosts possam
descobrir os roteadores existentes em seu enlace.
• Prefix Discovery: Faz a distinção do prefixo para os endereçamentos
link local ou link global direrecionando o pacote para o seu destino.
• Parameter Discovery: Como os hosts aprendem os parametros dos
links, como a ligação da MTU ou parametros da Internet.

34. 17
• Address Autoconfiguration: Realiza a configuração dos endereços
das interfaces automoaticamente.
• Next-hop Determination: Algoritmo para mapear os endereços IPs de
destinos.
• Duplicate Address Detection: Como os hosts determinam que o
endereço que se deseja utilizar em sua interface já esteja sendo
utilizado na rede.
• Neighbor Unreachability Detection: Recurso do IPv6 no qual um host
controla se um host vizinho está acessível, proporcionando uma melhor
detecção de erros e recuperação quando os hosts se tornam
indisponíveis repentinamente
Para cumprir estas tarefas são utilizados cinco tipos distintos de pacote
ICMPv6:
• Router Solicitation: Mensagem enviada pelos terminais para os
roteadores, solicitando uma mensagem Router Advertisement.
• Router Advertisement: Mensagem enviada pelos roteadores,
periodicamente ou por solicitação, para informar as configurações.
• Redirect Messages: Mensagem enviada pelos roteadores para informar
um terminal do primeiro “salto” para um destino.
• Neighbor Solicitation: Mensagem enviada por um host para determinar
o endereço de nível lógico do host vizinho;
• Neighbor Advertisement: Mensagem enviada em resposta à
mensagem Neighbor Solicitation.
2.2.4.3 Autoconfiguração:
O IPv6 define dois mecanismos de autoconfiguração dos endereços IP:
o “stateful” e o “stateless”.

35. 18
A autoconfiguração do tipo stateless, não necessita de configuração
manual de hosts, nem de servidores adicionais, necessitando apenas de uma
configuração mínima dos roteadores. Esse tipo de configuração é uma
característica chave do IPv6, permitindo que o próprio host gere suas próprias
configurações, a partir de uma combinação de informações disponíveis
localmente e de informações anunciadas pelos roteadores. Em alguns
cenários, a autoconfiguração stateless simplifica muito o processo de
renumeração de endereços de rede, exigindo somente que a interface de rede
seja capaz de enviar e receber pacotes multicast. Os hosts IPv6 (hosts e
roteadores) criam, automaticamente, endereços link-local únicos para todas as
interfaces de rede, combinando o endereço da camada de enlace no formato
EUI-64 com os 64 bits do prefixo local. O endereço EUI-64 de 64 bits é definido
pelo Instituto de Engenheiros Elétricos e Eletrônicos (IEEE).
O host IPv6 utiliza o mecanismo Duplicade Address Detection (DAD)
para determinar se o endereço já está sendo utilizado. Os hosts IPv6 utilizam
as mensagens Router Advertisement recebidas para montar o restante da
configuração como o default gateway, o valor pré-definido para o campo “Hop
Limit” no cabeçalho IPv6, os contadores utilizados nos processos de ND, a
MTU da ligação local e a lista de prefixos de rede definidos para o segmento de
rede em que se encontra. Cada mensagem de RA contém o prefixo da rede
IPv6 e seus Time to Live (TTL’s) válidos. Se indicado, o prefixo de rede é
combinado com o endereço MAC da interface e, assim, o endereço stateless
IPv6 é criado. Os pacotes RA’s possuem duas flags que indicam para o host se
deve ou não utilizar da autoconfiguração stateful ou stateless. Essas flags são:
managed address configuration e a outra é a stateful configuration indicando
aos hosts a utilização da configuração stateful para obter informações
adicionais (excluindo seu próprio endereços) como, por exemplo, o endereço
do servidor DNS da rede. Isto é importante, pois na autoconfiguração stateless
não há como enviar para os clientes o endereço de um servidor DNS.
2.2.4.4 DHCPv6
O DHCP para o IPv6 ou DHCPv6 funciona num modelo cliente/servidor
assim como era no IPv4, permitindo aos servidores DHCP atribuir endereços

36. 19
IPv6 e outros parâmetros de configuração aos host IPv6. Este protocolo é a
alternativa statefull à autoconfiguraçao stateless. Para um cliente IPv6, o
processo de aquisição de dados de configuração é semelhante ao utilizado no
IPv4. Se for encontrado um roteador na rede, primeiramente o cliente examina
os RA’s provenientes desse roteador para, assim, determinar se o DHCP deve
ou não ser utilizado ou, caso não encontrem nenhum roteador, o cliente irá
contactar diretamente o servidor DHCP. Os clientes e o servidor trocam
mensagens DHCP utilizando o protocolo de transporte UDP; para isso os
servidores recebem as mensagens dos clientes no endereço link-local multicast
reservado, denominado All DHCP Relay Agents and Servers. Este endereço
possui o seguinte formato: FF02::1:2 .Um cliente DHCP envia a maioria das
mensagens para este endereço multicast reservado. Para um cliente DHCP
enviar mensagens para o servidor DHCP que não está no mesmo segmento de
rede existe um DHCP Relay Agent responsável por transmitir as mensagens
entre o cliente e o servidor, de forma ao cliente não ficar “desamparado”.
Opcionalmente, o servidor pode oferecer ao cliente, além de endereços IPv6,
outros parâmetros de configuração como DNS, NTP, BOOTP, etc. Mas, não é
possível enviar o endereço do default gateway, pois esta informação deve
sempre ser obtida através da autoconfiguração stateless. O DHCPv6 fornece
um maior controle do que somente as configurações obtidas na
autoconfiguração stateless que, ao contrário do DHCPv6, não permitem, por
exemplo, que um administrador de rede defina políticas de acessos. Com isso,
todos os hosts que se ligam à rede podem obter endereços IPv6 e os
servidores DHCPv6 possuem os meios para assegurar o controle de acesso a
recursos de rede, verificando, primeiro, as políticas de controle de acesso,
antes mesmo de responder aos pedidos dos clientes. Outros benefícios do
DHCPv6 são: pode ser utilizado, simultaneamente, com as configurações
stateless, por exemplo; pode-se obter um endereço IPv6 da autoconfiguração
stateless e o endereço do servidor DNS do DHCPv6 pode ser utilizado para
delegar um prefixo IPv6 para equipamentos terminais.(BRADNER,1996)

37. 20
2.2.4.5 DNSv6
O serviço de DNS é o que faz o mapeamento dos nomes para os
endereços IP e vice-versa. O DNS utiliza um espaço de nomes hierárquico no
qual os servidores ajudam a relacionar os nomes com os endereços em cada
nível hierárquico, mas ele foi concebido para processar endereços IPv4 de 32
bits. Dessa forma, nos últimos anos, foram criadas algumas extensões para
tornar o DNS compatível com o IPv6. Algumas delas ainda estão em utilização
e outras já foram descontinuadas. Em utilização estão: o registro quad-A
“AAAA”, a nova representação textual no registro, o domínio ip6.arpa e novas
consultas DNS. Dentre as extensões experimentais ou descontinuadas estão:
os registros A6 e DNAME, o Binary Labels Type e o domínio ip6.int. Não é
suficiente ter registros IPv6 (AAAA) no DNS, é também de grande importância
efetuar consultas e obter respostas DNS utilizando a camada de transporte
IPv6 com todas suas características. É claro que os dados obtidos via IPv6 têm
de ser iguais aos obtidos via IPv4 para que haja interação entre as duas
versões. Relativamente aos servidores DNS Raiz, apenas alguns destes
podem ser alcançados através do IPv6. O registro AAAA faz o mapeamento do
nome de um host para um endereço IPv6, sendo equivalente ao registro A do
IPv4. Este registro AAAA possui o seguinte formato: “www.xxxxx.com AAAA
3FFE:B00:C18:1::2” . O IETF decidiu utilizar este registro para a resolução do
nome no correspondente endereço IPv6; já o registro PTR faz o inverso; ou
seja; é um “apontador” que mapeia endereços para nomes; ou também
conhecido como mapeamento reverso (BRADNER,1996). Esses registros
utilizam o seguinte formato:
2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.1.0.0.0.8.1.c.0.0.0.b.e.f.f.3. ip6.arpa PTR
www.xxxxx.com exatamente como no IPv4, ou seja, o endereço invertido, mas
colocado de forma explícita, e com um ponto separando cada conjunto de 4
bits. Foi também definido um domínio específico para pesquisar os registros
que contém endereços IPv6, e a intenção deste domínio é fornecer uma forma
de mapear um endereço IPv6 para um nome, embora possa ser utilizado para
outros fins também, e tem sua raiz em IP6.ARPA. Finalmente, as “queries”

38. 21
DNS foram alteradas de modo a ser possível localizarem e processarem não
somente endereços IPv4, mas também os novos endereços IPv6.
2.2.4.6 Multicasting
O multicasting é, sobretudo, utilizado por aplicações multimídia. Estas,
freqüentemente, precisam de muita largura de banda para transmitir dados de
uma única fonte para vários destinatários. Um exemplo é o de videoconferência
como na figura abaixo:
Figura 2.10 – Exemplo de vídeo conferência
É também utilizado por alguns provedores de acesso à Internet para
fornecer serviço de TV por assinatura aos seus clientes Asymmetric Digital
Subscriber Line (ADSL). Os endereços IPv6 multicast têm o prefixo FF00::/8. É
utilizado um campo “Scope ID” de 4 bits para especificar o intervalo de
endereços multicast reservado para cada âmbito, permitindo assim, um
controle fácil da fronteira multicast. Um host pode subscrever a diferentes
endereços multicast e, ao mesmo tempo, obter todo fluxo de dados referente
aos endereços multicast que subscreveu. Comparativamente ao IPv4, o IPv6
fornece um leque maior de endereços multicast, que oferece novas
perspectivas para atribuição de endereços. Uma das principais inovações
introduzidas pelo IPv6 na área de multicasting é a de que todas as

39. 22
implementações IPv6 terão de incluir suporte nativo a este serviço IP. O
protocolo Multicast Listener Discovery (MLD), definido na RFC 2710, é utilizado
para determinar os membros de grupos num segmento de rede e também
responsável pela gestão multicasting entre hosts e roteador já não é delegado
para um protocolo em separado como no IPv4 e, por isso, tem de ser
suportado em todas as pilhas do protocolo IPv6. O protocolo MLD faz, de fato,
parte do pacote ICMPv6 e pode ser utilizado por um roteador IPv6 para
descobrir a presença de Multicast Listeners nas suas ligações diretas e para
descobrir, especificamente, que endereços multicast têm interesse para com os
hosts vizinhos. Existem três tipos de mensagens MLD, que são distinguidas
pelo campo “type”: “Multicast Listener Query”, “Multicast Listener Report” e
“Multicast Listener Done”. O MLD já obteve uma atualização para o MLDv2 e a
novidade nesta versão é que o receptor pode especificar grupos e fontes de
interesse, sendo necessário para serviços SSM. Dos dados fornecidos por esta
nova versão do MLD, são criadas árvores de distribuição em toda a rede
Multicast IPv6, utilizando o protocolo PIM. A grande diferença no multicast IPv4
está relacionada com o problema de inter-domínio. O protocolo Multicast
Source Discovery Protocol (MSDP) foi concebido para o IPv4, para permitir que
as informações da origem fossem trocadas entre domínios.
2.2.4.7 QoS
A expressão Qualidade de Serviço, em inglês Quality of Service (QoS) é
muitas vezes utilizada para descrever as garantias de desempenho que uma
rede fornece ao tráfego transportado. Os novos requisitos, com maiores
exigências impostas pelas novas aplicações on-line, como Voz sobre IP,
videoconferência de alta qualidade, jogos on-line, necessitando de garantia de
banda no tráfego das aplicações e, também, sendo sensíveis aos retardos
maiores e perda de pacote. As atuais redes de alta velocidade seguem a
filosofia de Differentiated Service (DiffServ), de forma que o QoS cumpra os
requisitos mencionados. O cabeçalho IPv6 inclui dois campos relativos ao QoS:
Traffic Class e Flow Label.

40. 23
O campo “Traffic Class” de 8 bits permite ao host de origem ou a um
roteador identificar a prioridade do pacote. Este campo é análogo ao campo
“Type of Service” do cabeçalho IPv4.
Figura 2.11 – Cabeçalho IPv4 e IPv6 - apresentação QoS
Já o campo “Flow Label” possui 24 bits e foi proposto para identificar
pacotes de um fluxo específico; para isso, o host de origem atribui o mesmo
valor ao campo “Flow Label” para cada pacote transmitido pertencente a um
fluxo e os valores permanecem inalterados à medida que o pacote é
transportado pelas redes. Também é esperado que o campo “Flow Label” no
cabeçalho IPv6 simplifique o fornecimento de serviços que necessitam
diretamente do QoS para funcionarem satisfatoriamente.
2.2.5 Segurança no IPv6
Os principais objetivos de segurança do IPv6 são iguais aos objetivos de
segurança em qualquer infra-estrutura de redes. Estes incluem: robustez da
infra-estrutura; autenticação, confidencialidade e integridade; não rejeição
explícita, controle de acesso e contabilização e registro. Em IPv6, para atingir
estes objetivos, tem de ser verificadas diversas ameaças existentes e, dentre
elas, serão discutidas sete: pesquisa de pontos fracos em gateway e hosts,
pesquisa de endereços multicast, acesso não autorizado, exposição de pontos
fracos devido ao NAT e pontos fracos do próprio, firewall, ataques de
desempenho com cabeçalhos fragmentados, pontos fracos do protocolo e
ataques do tipo Denial of Service (DDoS). (BRADNER,1996).
2.2.5.1 Ameaça I – Procura de Gateways
Uma primeira ameaça de segurança é a procura de gateways, por
hackers ou sistemas que pretendem entrar na rede ou atacá-la. Estes analisam
todos os endereços externos de gateways ou hosts que encontram e procuram
pontos fracos na sua segurança. Devido ao tamanho do espaço IPv6, a
pesquisa por sistemas vulneráveis na rede tornou-se mais complexa, por

41. 24
exemplo, a varredura por exaustão ficou bastante dificultada. Além disso, o
software de análise de portas, tal como NMAP, não suporta sequer a análise de
rede em IPv6. Por esta razão, os métodos de análise em IPv6 poderão vir a ser
alterados, mas, obviamente, a pesquisa continuará a ocorrer. Como são
necessários que os servidores públicos estejam registrados no DNS, os
atacantes continuarão a ter hosts para atacar. Além disso, os administradores
podem também adotar endereços fáceis de lembrar e, neste caso, a parte do
endereço EUI-64 facilita o trabalho do atacante. Sendo assim, as novas
técnicas para os endereços obtidos podem utilizar informações de zonas DNS
ou arquivos “logs”.
2.2.5.2 Ameaça II – Procura de Endereços Multicast
A segunda ameaça consiste na procura de endereços multicast, pois é
esperado que todas as implementações IPv6 suportem multicast. Os novos
endereços multicast suportados pelo IPv6 podem permitir aos atacantes
identificar, no segmento de rede, recursos essenciais e atacá-los. Os
endereços multicast “all-node” e “all-router” podem, também, ser usados como
novas formas de intrusão. De forma a tornar os endereços multicast
inacessíveis do exterior, regras de firewall devem ser criadas nas bordas para a
filtragem. A segurança dos endereços IPv6 pode ser melhorada utilizando
endereços gerados com auxilio de cifras, ou também conhecidos como CGA’s.
Estes são endereços IPv6 que transportam, no identificador, informação de
hash sobre a chave pública e, apesar de manterem a privacidade, é também
possível aos administradores de rede a manutenção de registros. Os
endereços gerados com auxilio de cifras estabelecem um vinculo entre
endereços IP e chaves públicas, sem a necessidade de uma infra-estrutura de
gestão de chaves. Adicionalmente, CGA’s podem ajudar a proteger o protocolo
e reforçar a proteção de informações em mobilidade IPv6.
2.2.5.3 Ameaça III – Acesso não Autorizado
A terceira ameaça é o acesso não autorizado, e no IPv6, a
implementação de políticas das camadas 3 e 4 ainda é efetuada nos firewalls.
No entanto, existem algumas considerações sobre essa arquitetura: os

42. 25
endereços multicast (direcionados ao tráfego interno) devem ser filtrados nos
limites do domínio de rede; os endereços “IPv4 mapped IPv6” devem ser
filtrados em tempo real; e devem existir múltiplos endereços por interface de
rede. A mobilidade em IPv6 utiliza o Protocol for Autentication and Network
Access (PANA), de forma a evitar acessos não autorizados. O PANA fornece
uma solução para a camada de enlace, permitindo a autenticação no acesso à
rede, diferentemente do que ocorria no IPv4, onde um host interagia com um
agente externo para efetuar sua autenticação. Nas redes IPv6 móveis, esta
função de autenticação não é mais efetuada pelo Agente Externo, mas sim
pelo PANA Authentication Agent (PAA).
2.2.5.4 Ameaça IV – Pontos Fracos nos Firewalls
Os pontos fracos em firewalls são a quarta ameaça. Em IPv6 os firewalls
podem ser configurados de diversas formas No entanto, para eliminar os
pontos fracos, tanto a arquitetura do IPv6 como a do próprio firewall têm de
cumprir determinados requisitos. No IPv6 o nível de segurança é aumentado
devido ao fechamento de túnel “fim-a-fim” oferecida pela implementação do
IPSec que é intrínseca ao protocolo . Por não ter a necessidade de utilização
do NAT, os pontos fracos da filtragem de pacotes já não podem ser mais
ocultados. Adicionalmente, a arquitetura IPv6 e a dos firewalls tem que suportar
o encadeamento do cabeçalho IPv6, assim como a transição e coexistência
IPv4/IPv6. Apesar da complexidade adicional dos gateways, deve ser
assegurada a inexistência de pontos fracos.
2.2.5.5 Ameaça V – Ataques Através de Cabeçalhos
A quinta ameaça consiste em ataques de desempenho através de
cabeçalhos fragmentados. De forma a evitá-los, o administrador de rede IPv6
deve rejeitar os fragmentos IPv6, recusando, por exemplo, todos os pacotes
com um cabeçalho de encaminhamento, caso a rede não suporte Mobile
Internet Protocol Version 6 (MIPv6). Todos os fragmentos com menos do que
1280 octetos podem ser potencialmente descartados com exceção do último
fragmento. E finalmente, todos os fragmentos devem ser entregues em, no
máximo, 60 segundos e recusados, caso contrário.

43. 26
2.2.5.6 Ameaça VI – Pontos Fracos do Protocolo
A sexta ameaça deriva de pontos fracos do próprio protocolo. No IPv4,
estes pontos fracos podem conduzir a spoofing de nível 3 e 4 ou ataques
Address Resolution Protocol (ARP) ou DHCP, no entanto, os gateways entre os
dois mundos IP ainda continuam a ser um potencial alvo. Embora o spoofing na
camada 3 permaneça similar, os endereços IPv6 são agregados globalmente,
facilitando, assim, a atenuação de spoofing em pontos de agregação. A
atenuação do spoofing é facilitada, visto que o endereçamento IPv6 é
hierárquico. Por uma questão de registro e contabilização, é necessário
mapear o endereço IPv6 para um endereço MAC. Com o ND, as ferramentas
de ataque, tais como “ARP cache poisoning” e “DHCP Snooping”
desapareceram.
2.2.5.7 Ameaça VII – Ataques de DDoS
A última ameaça recai nos ataques de DDoS. Os ataques de “broadcast
amplification” e “Smurf”, que enviam pacotes ICMP para endereços broadcast,
são completamente eliminados no IPv6, já que, no IPv6, não se utiliza
broadcast, e sim endereços multicast globais em seu lugar; além disso, a
própria especificação do protocolo IPv6 proíbe a geração de pacotes ICMPv6
em resposta a mensagens para endereços multicast globais.
Tal como nas redes IPv4, as redes IPv6 tem de lidar com diversas
ameaças como descrito acima. Os serviços de segurança IPSec dependem
inteiramente destes mecanismos: Authentication Header (AH) e Encapsulation
Security Payload Header (ESP).
Figura 2.11 – Cabeçalho AH e ESP

44. 27
Estes cabeçalhos são definidos tanto para IPv4 quanto para o IPv6 mas
quando utilizados no IPv4, são adicionados como opções ao cabeçalho IPv4
normal. A utilização é então opcional no IPv4, mas é obrigatória no IPv6. O
IPSec fornece os seguintes serviços de segurança de rede opcionais:
confidencialidade dos dados, pois o emissor IP pode cifrar os pacotes antes de
enviá-los através da rede, integridade dos dados, pois o destinatário IPSec
pode autenticar os pacotes enviados pelo emissor IPSec, e assegurar que os
dados não sofreram qualquer tipo de alteração durante a transmissão. A gestão
de chaves requer uma infra-estrutura Public Key Infrastructure (PKI) e uma
nova e simplificada Internet Key Exchange (IKE) denominada IKEv2. Outra
opção é a autenticação da origem dos dados, pois o destinatário, para
autenticar a origem dos pacotes IPSec enviados, depende diretamente do
serviço de integridade dos dados. O IPSec impede assim a observação,
modificação e spoofing dos dados enviados através de uma rede pública. A
funcionalidade IPSec é, essencialmente, idêntica no IPv6 e no IPv4; no
entanto, o IPSec no IPv6 pode ser utilizado fim-a-fim e os dados podem ser
cifrados em todo o caminho entre o host de origem e o host de destino. Com o
IPSec, o IPv6 terá uma menor probabilidade de ser vítima de sniffing ou de um
ataque do tipo “man in the middle” do que o IPv4. Adicionalmente, para
prevenir ataques de encaminhamento no IPv6, o IPSec pode proteger
protocolos como o Open Shortest Path First Version 3 (OSPFv3) e o RIPng.
Por estas razões, os administradores de rede devem ativar o IPSec em todos
os hosts IPv6 tornando a rede potencialmente mais seguras.
Foram descritas, neste capítulo, as principais características do
protocolo IP versão 6, feita uma comparação com sua versão 4 e expostas
suas diferenças e melhorias. No próximo capítulo serão descritas as formas de
coexistência e interações entre as duas versões do protocolo.

45. 28
3. PROCESSOS DE UMA MIGRAÇÃO – COEXISTÊNCIA
IPv4/IPv6 E SUPORTE
Será apresentado neste capítulo, os mecanismos de coexistência e
interação entre as duas versões do protocolo IP abordando os processos de:
tunelamentos, traduções, segurança dos mecanismos e sistemas operacionais
e o grau de maturidade da pilha IPv6 nos software e firmware.
3.1 Premissas
O “gatilho” inicial de uma migração de uma estrutura estável e funcional não
é disparado facilmente. Ele deve ser convincente e extremamente necessário,
pois se estará mexendo diretamente com a confiabilidade, estabilidade e
robustez da rede e seus serviços. Esse “gatilho” poderá ter início, na maior
parte dos casos, a partir de duas entidades distintas que são as mais
interessadas: a operadora de telecom ou o administrador da rede.
O administrador da rede teria necessidade de migrar sua rede de IPv4 para
IPv6 pelos seguintes motivos:
1) A operadora iniciar a oferta de pools IPv6 e a restrição de endereços
IPv4 válidos;
2) O aumento de sites e serviços on-line baseados puramente em IPv6
3) Em menor escala, mas também possível, é a necessidade de
utilização do IPSec nativo do IPv6 para aumento da segurança da
comunicação interna entre os hosts.
Supondo que a operadora de Telecom forneça apenas um pool IPv6 válido
e somente um único IPv4 (prefixo de 30 bits) para o cliente. Entra-se, então, no
cenário em que a rede interna, controlada pelo administrador, é IPv4 pura, e a
operadora oferece 1 (um) único endereço IPv4 público e um pool de endereços
(/48 a /56) IPv6, ou seja, se houver necessidade de se ter mais serviços e IP’s
válidos, o uso de IPv6 torna-se obrigatório. Sob esse cenário o administrador
da rede pode-se ver compelido a iniciar o processo de migração.

46. 29
3.2 Mecanismos de coexistência e suas falhas
Para facilitar a transição entre o IPv4 e o IPv6 foram desenvolvidas
técnicas, de forma a manter sua coexistência e compatibilidade por todo o
processo de transição para o IPv6 puro.
Essas técnicas, por sua vez, possuem características específicas com seus
PRÓS e CONTRAS, podendo ser utilizadas concomitante ou individualmente,
de acordo com a necessidade.
Existem atualmente três categorias mais usuais para esses mecanismos de
transição:
1) Dual-stack ou simplesmente pilha dupla: que é o IPv4 e o IPv6
habilitados na mesma interface de rede;
2) Tunelamento: tráfego de pacotes IPv6 sobre redes IPv4 ou vice-versa;
3) Tradução: que se restringe à comunicação entre hosts IPv4 puros com
hosts IPv6 puros.
Apesar de, num futuro próximo, ser possível ter redes totalmente IPv6, o
mais comum será ter IPv4 e IPv6 na mesma infra-estrutura; e, para permitir
isto, são necessários ferramentas e mecanismos de coexistência e integração
(HAGEN, 2002). Considerando que haverá diversos serviços que ainda
utilizarão o protocolo IPv4, a coexistência entre as duas versões de protocolos
será duradoura, tornando os mecanismos acima de vital importância para esse
período, chamado de “misto” e, assim, tentar garantir que a migração seja
suave, segura e que não surjam isolamentos de comunicação em nenhum
momento.
A internet é constituída por centenas de milhares de redes IPv4 e
milhões de hosts IPv4. Para que a adoção do IPv6 seja bem sucedida, é
necessária uma introdução gradual, sendo que o principal desafio passa por
efetuar a integração e a transição o mais transparente possível para os
usuários (SILVA,2002).

47. 30
Figura 3.1 – Coexistência - IPv6 e IPv4
Há a expectativa de que o IPv4 e o IPv6 coexistam durante um longo
período de tempo e, considerando este cenário, os três tipos de mecanismos
podem ser empregados: Em algumas redes, como por exemplo, pequenas
redes empresariais, será possível a coexistência de IPv4 e de IPv6 na mesma
infra-estrutura, usando o dual-stack (pilha dupla) e, assim, as aplicações e
serviços podem utilizar um dos protocolos, fazendo com que este mecanismo
seja o preferido. Contudo, é necessária uma forma destas redes IPv6 se
comunicarem entre si, isto é, transportar IPv6 sobre a rede IPv4 existente hoje
das operadoras. Para estes casos os túneis são a resposta mais certa.
E em alguns casos, os sistemas IPv4 necessitam se comunicar com
sistemas IPv6. Essa é a situação mais complexa de implantação, pois são
necessários sistemas de “tradução” entre o IPv4 e o IPv6. A tradução, neste
caso, pode ocorrer na camada IP, de transporte ou de aplicação. A forma mais
simples de introduzir IPv6 numa rede passa pela utilização de dual-stack, o que
permite que as aplicações IPv4 e IPv6 coexistam na mesma rede, sendo que a
comunicação IPv4 é efetuada pela pilha IPv4 e a IPv6 pela pilha IPv6. Os
mecanismos de tunelamento obrigam que os hosts finais do túnel suportem o
dual-stack e uma interface virtual de tunelamento. Um equipamento dual-stack
com interface virtual de tunelamento pode enviar pacotes IPv6 através de um
túnel IPv4, para um host remoto IPv6, sem existência de infra-estrutura IPv6.

48. 31
3.2.1 Pilha dupla (dual-stack)
O dual-stack é um método para integrar, ativamente, o IPv6 e, assim,
não são necessários mecanismos reais de tradução. Na maioria das
plataformas, para que um host passe a ser dual-stack é necessário que se
habilite o IPv6 ou uma atualização de firmware, para que o IPv6 seja
incorporado. Deste modo, o host passa a ter uma stack híbrida, com
capacidades IPv4 e IPv6 completas. A comunicação por IPv4 utiliza esse
protocolo para o encaminhamento de pacotes IPv4, baseados em rotas
aprendidas por protocolos de encaminhamento específicos do IPv4. A
comunicação IPv6, por sua vez, utiliza a pilha IPv6, através das rotas
descobertas pelos protocolos de encaminhamento IPv6. A introdução de dual-
stack em uma rede permite que os hosts terminais e as aplicações efetuem
uma migração baseada do IPv4 para o IPv6. Foi, também, definida uma nova
API com suporte de endereços e de pedidos DNS IPv4 e IPv6. Quando os dois
protocolos estão disponíveis, as aplicações utilizam IPv4 ou IPv6 dependendo
da resposta do servidor DNS. A aplicação, então, seleciona o endereço de
destino, com base no tipo de tráfego IP e nos requisitos particulares da
comunicação.
Assim que o IPv6 é habilitado, há certas medidas de segurança que
devem ser tomadas para proteger a rede, esta medidas serão descritas no
capítulo de configurações e melhores práticas. Atualmente, o encaminhamento
dual-stack é a melhor estratégia para introdução do IPv6.
Figura 3.2 – Tráfego de pacotes com a arquitetura de pilha dupla

49. 32
Assim, cada host que possuir o método dual-stack vai possuir
endereçamento IPv4 atribuído por DHCPv4, ou mesmo manualmente, e IPv6
atribuído por DHCPv6 ou stateless, de acordo com a configuração adotada
pelo administrador. Este método permite uma transição gradual, para que, caso
um host específico (como uma impressora de rede) que, em seu firmware,
possua suporte somente a IPv4 possa se comunicar com os demais hosts da
rede (hosts IPv4 ou IPv4/IPv6). Com isso, o administrador pode ir implantando
serviços e, com o tempo, ir trocando o hardware obsoleto por dispositivos que
suportem IPv6 até o momento em que toda a rede utilize somente tráfego IPv6
e, então desabilitar a pilha IPv4 nos hosts.
O método dual-stack não é livre de falhas, e possui algumas implicações
nas configurações de alguns serviços de rede, que devem ser analisadas antes
de sua implementação. Alguns dos serviços que precisam sofrer alterações são
o DNS, o DHCP, a configuração dos protocolos de roteamento e,
principalmente, regras do firewall.
3.2.1.1 Segurança em dual-stack (Pilha Dupla)
A maior parte dos problemas do dual-stack está relacionada à forma
com que o sistema operacional que realiza a função de pilha dupla vai tratar a
obtenção e manutenção desses dois ou mais endereços. Dar preferência à
comunicação IPv6 sobre a IPv4 é o que prescreve a RFC 3484: “The default
policy table gives IPv6 addresses higher precedence than IPv4 addresses.
This means that applications will use IPv6 in preference to IPv4 when the two
are equally suitable.”. Mas a implementação depende do fabricante do
software. Basicamente a utilização de dual-stack não aumenta em si as falhas
de segurança individuais do protocolo IPv4 ou IPv6 como é descrito na RFC
4477: “... There are no security considerations in this problem statement per se,
as it does not propose a new protocol”. Maiores detalhes estão descritos na
RFC 4477.
3.2.2 Tunelamento
O tunelamento se baseia em encapsular todo o tráfego IPv6 em pacote
IPv4, de forma a permitir uma comunicação entre dois hosts puramente IPv6,

50. 33
através de uma rede puramente IPv4. Essas técnicas são tratadas na RFC
4213 e tem sido muito utilizadas no início da implantação e testes da tecnologia
do IPv6. Várias formas de layout de túneis podem ser configuradas, entre eles
são:
a) Host-a-Host – permite a hosts dual-stack conversarem entre si por
uma rede IPv4, utilizando pacotes IPv6 encapsulados em pacote
IPv4. Consiste em uma comunicação direta tipo P2P, é utilizada na
maioria dos tipos de tunelamento e será bastante citada neste
capitulo.
Figura 3.3 – Configuração Host a Host
b) Host-a-Roteador - Hosts IPv6/IPv4 enviam pacotes IPv6 a um
roteador IPv6/IPv4 intermediário via rede IPv4, ligando o primeiro
segmento no caminho entre dois hosts, permitindo a comunicação
entre esses dois hosts por IPv6;

51. 34
Figura 3.4 – Configuração Host a Roteador
c) Roteador-a-Roteador – gateways dual-stack IPv6/IPv4 e com uma
conexão IPv4 entre si são configurados para trocarem pacotes IPv6
de redes IPv6 passando por uma rede IPv4 (por exemplo a rede da
operadora de Telecom) permitindo a comunicação de dois
segmentos de rede IPv6;
Figura 3.5 – Configuração Roteador a Roteador

52. 35
O encapsulamento, de uma forma geral, é algo simples e dinâmico. O
primeiro host (A) pega o pacote IPv6 e o insere em um pacote com cabeçalho
IPv4 e então o transmite. O host de destino (B) recebe esse pacote IPv4,
desencapsula retirando o cabeçalho IPv4 e processa o pacote IPv6 recebido.
Camada de Aplicação
TCP/UDP TCP/UDP
IPv6 IPv4
Camada
de
Enlace
Figura 3.6 – Pilha Dupla IPv6 encapsulado IPv4
Essa forma de encapsulamento é conhecimento como protocolo 41 ou
como 6in4 e é utilizado nos tipos de tunelamento que serão vistos a seguir:
ISATAP, 6to4 e Túnel Broker (com exceção do TEREDO).
Os túneis podem ser criados com configuração manual, que podem utilizar
mecanismos genéricos de encapsulamento. Há, também, mecanismos de
criação semi-automáticas de túneis, como, por exemplo, os serviços de túnel
Broker e existem, também, mecanismos totalmente automáticos para a criação
de túneis, por exemplo: o 6to4, o ISATAP ou o Teredo.
Túneis manuais são usados entre dois pontos e necessitam da
configuração dos endereços de origem e destino do túnel. Os túneis
automáticos necessitam apenas serem ativados, e o respectivo protocolo é
responsável pela criação e manutenção dos túneis.
As variedades de cenários existentes corroboram com a existência de
diversos tipos de túneis, com variações em desempenho, implementação e
segurança. Algumas técnicas de tunelamento serão descritas abaixo:

53. 36
3.2.2.1 Túneis ISATAP
O tipo de tunelamento Intra-Site Automatic Tunnel Addressing Protocol (
ISATAP), tem sua fundamentação em túneis criados pelo roteador ISATAP
com prefixos definidos para clientes IPv4 se comunicarem com hosts IPv6. O
prefixo definido no roteador ISATAP é associado ao endereço IPv4 do cliente
formando assim um endereço IPv6, facilitando ao host ISATAP determinar os
pontos de entrada e saída dos túneis. Este processo melhor explicado e
definido na RFC 5214 juntamente com a RFC 4213, para a criação de túneis
6in4 com o uso do protocolo 41.
Figura 3.8 – Estrutura de pacote ISATAP
Figura 3.9 – Topologia utilizando túnel ISATAP
A figura 3.9 mostra a estrutura de um pacote ISATAP, onde:
• Prefixo Unicast : Prefixo escopo link-local (FE80::/64) ou Prefixo
escopo global fornecido pela operadora;

54. 37
• ID IPv4 público ou privado: Aqui se diferencia o tipo de endereço IPv4,
podendo ser endereço público ou privado. Se for público, o campo deve
conter o valor "200", se for privado (192.168.0.0/16, 172.16.0.0/12 e
10.0.0.0/8) o valor do campo é zero;
• ID ISATAP: Valor fixo referente ao tipo ISATAP que é 5EFE;
• Endereço IPv4: É o endereço puro IPv4 no formato convencional;
Um exemplo de endereço ISATAP de um endereço IPv4 público
201.200.45.1 seria 2001:10fe:0:8003:200:5efe:201.200.45.1. Note que somente
o prefixo da rede 2001:10fe:0:8003 mais 200, ID IPv4 público, mais o prefixo
ISATAP :5efe são adicionados ao endereço IPv4 para a composição do
endereço ISATAP.
O ISATAP também monta um endereço de escopo link-local utilizando-se
das regras mostradas acima, mas com o IPv4 do cliente (prefixo “FE80::/10”) e,
em se tratando de uma comunicação interna (entre clientes ISATAP na mesma
LAN), essa interface é utilizada.
3.2.2.1.1 Modelo de comunicação ISAPTAP
Para a criação do túnel ISATAP, o processo de inicialização é descrito nos
passos a seguir:
a) O cliente determina o endereço do roteador ISATAP que pode ser
atribuído por resolução DNS ou por configuração manual do cliente;
b) O cliente, então, envia um pacote IPv4 de RS (Router Solicitation) ao
roteador ISATAP;
c) O Roteador ISATAP devolve, em resposta à requisição do cliente, um
RA (Router Advertisement) em IPv4.
d) De posse dessa informação, o cliente configura seus endereços
IPv6/ISATAP.

55. 38
Figura 3.10 – Inicialização do ISATAP
Depois de configurada a interface virtual ISATAP, a comunicação deste host
a um host IPv4 puro é feita por IPv4 de sua interface normal. No caso da
comunicação entre dois clientes com o ISATAP configurado depois de suas
respectivas inicializações os seguintes passos são tomados:
a) O cliente C2 (ISATAP) utiliza o protocolo 41 para enviar um pacote IPv6
(ISATAP) encapsulado em IPv4 para o endereço IPv4 do cliente C1;
b) O cliente C1 (ISATAP) recebe o pacote e desencapsula sobrando então
o pacote IPv6 (ISATAP).
c) O cliente C1 (ISATAP) utiliza novamente o protocolo 41 para encapsular
o pacote IPv6 (ISATAP) com um cabeçalho IPv4 e retransmite para o
endereço IPv4 de C2.

56. 39
Figura 3.11 – Comunicação entre máquinas com ISATAP configurada no mesmo
segmento de rede.
O ISATAP também fornece suporte à comunicação entre clientes em
sub-redes distintas. Os clientes, neste caso utilizam seus roteadores
específicos como gateways para alcançarem um ao outro:
Figura 3.12 – Comunicação entre máquinas com ISATAP configurada em diferentes
segmentos de rede.
a) O cliente C1 (ISATAP) envia um pacote IPv6 encapsulado no protocolo
41 para o endereço IPv4 do roteador R1;
b) O roteador R1, desencapsula o pacote IPv4 (protocolo 41) utilizando a
interface virtual ISATAP. De posse do endereço IPv6 do destino ele

57. 40
reenvia (utilizando uma rede IPv6) pura para o outro roteador R2, que,
neste caso, também é ISATAP;
c) R2, então, recebe o pacote IPv6 de R1 em IPv6 nativo e, verificando o
endereço de destino, sabe que ele pertence a sua sub-rede, mas não a
IPv4 e sim a ISATAP. R2 encapsula novamente o pacote em um pacote
IPv4 (protocolo 41) e transmite através de sua interface virtual ISATAP
para a interface virtual ISATAP do cliente C2 que, por sua vez,
desencapsula-o e extrai o pacote IPv6.
d) C2 responde, encapsulando o pacote IPv6 em IPv4 (protocolo 41), e o
reenvia através da interface virtual ISATAP para o endereço IPv4 do
roteador R2;
e) R2 recebe o pacote IPv6 encapsulado e o encaminha para sua interface
IPv6;
f) R1 recebe o pacote de R2 em IPv6, repassa o pacote para sua interface
ISATAP, encapsula novamente para IPv4 e o encaminha para o
endereço IPv4 de C1.
Ainda existe uma variante possível e importante nestes cenários, quando o
cliente ISATAP precisar conversar com um cliente IPv6 puro. Partindo
novamente da premissa de que toda a inicialização do cliente já foi efetuada
como mostrado anteriormente, o processo de comunicação é o que se segue:
TRÁFEGO IPV6
NATIVO
TRÁFEGO ISATAP
(IPv6 encapsulado
IPv6
com protocolo 41)
2
3
IPv4 11
14 ROTEADOR
ISATAP SERVIDOR
IPv6 NATIVO
C1
Cliente
ISATAP
Figura 3.13 – Comunicação entre máquinas com ISATAP – diferentes segmentos de
rede IPv6

58. 41
a) O cliente (ISATAP) inicia o envio de um pacote IPv6 encapsulado IPv4
(protocolo 41) por sua interface virtual ISATAP para o endereço IPv4 do
roteador ISATAP;
b) O roteador (ISATAP) desencapsula o pacote IPv4 na sua interface
virtual ISATAP e extrai o pacote IPv6; com o endereço IPv6 em mãos
ele envia o pacote para seu destino, que no exemplo, é o servidor com
endereço IPv6 puro;
c) O servidor IPv6 puro responde ao cliente ISATAP através de sua rota
padrão IPv6 (ou seja seu gateway é o roteador ISATAP);
d) O roteador de posse do pacote sabe que o destino é o cliente ISATAP:
com isso ele encapsula o pacote IPv6 na sua interface virtual ISATAP
(protocolo 41) e o encaminha para o cliente ISATAP que, por sua vez
desencapsula-o e trata a informação;
3.2.2.1.2 Segurança de Túnel ISATAP
Os pontos negativos em relação ao ISATAP são:
a) Incompatibilidade de alguns sistemas operacionais com a tecnologia
ISATAP, inclusive em se ter suporte ao cliente ISATAP.
b) As interfaces virtuais do tunelamento têm, geralmente, a segurança mais
vulnerável do que a interface real física, tendo em vista que o invasor
tem a possibilidade de enviar pacote IPv6 encapsulado de qualquer
lugar da Internet, ou mesmo interno à rede e, com isso, desencadear
ataques onde se injeta tráfego na rede invadida através de pacote IPv6
encapsulados com IPv4 (ISATAP), mas com endereço de origem falso.
Uma forma de se conter esse tipo de invasão seria criar regras IPv4 no
roteador ISATAP limitando o acesso à interface ISATAP apenas a hosts
conhecidos assim como a filtragem nos roteadores de borda de pacotes
utilizando o protocolo 41;

59. 42
c) Outro problema relacionado à interface virtual ISATAP é que, se o
tráfego for interno (entre dois clientes ISATAP, mas dentro da mesma
LAN), ele será feito pela interface virtual com todo o processo de
encapsulamento com o protocolo 41, ao invés da interface de escopo
link-local. Isso ocorre porque o ISATAP também cria um endereço de
escopo link-local e o mesmo obtém prioridade maior em relação à
interface link-local autoconfigurada (“FE80::/10), gerando, assim, um
maior processamento nos clientes.
3.2.2.2 Túnel 6to4
O tipo de tunelamento automático 6to4, que é definido na RFC 3056,
permite a conexão ponto-a-ponto entre hosts IPv6 em uma rede IPv4 ou sub-
redes IPv6 em uma rede também IPv4. Os endereços IPv6 são formados a
partir de um prefixo “2002::/10”, reservado pela IANA, que será utilizado única e
exclusivamente para túneis 6to4, e seguido do endereço IPv4 convertido em
hexadecimal como no exemplo 2002:aabb:ccdd::/48, onde aabb:ccdd é o
endereço IPv4 público do cliente já convertido para o formato hexadecimal de
dois dígitos.
Figura 3.14 – Estrutura do endereço do túnel 6to4
Como exemplo de transformação, utilizaremos o endereço IPv4:
201.64.70.2. Cada campo de 8 bits do endereçamento IPv4 é convertido em
seu respectivo hexadecimal de 2 dígitos:
Decimal Hexadecimal
201 C9
64 40
70 46
2 02

60. 43
Após a conversão, o endereço fica da seguinte forma 2002:C940:4602::
Neste modelo o campo ID da interface e o ID da subrede são utilizados para
segmentar a rede e pode ser colocado de forma dinâmica (por DHCP) ou
manual fixa.
Apesar da RFC 3056 determinar uma forma de construção de um endereço
de escopo link-local para uma interface 6to4, ela simplesmente foi deixada de
lado pelos implementadores das pilhas IP nos sistemas operacionais por não
ter utilidade real, pois o endereço formado não pode ser roteado. Ao invés de
se formar o endereço link-local com a interface virtual 6to4 o sistema
operacional, utilizando dual-stack, simplesmente utiliza o endereço formado
automaticamente por sua interface de rede física com o prefixo “FE80::/10”.
O layout da conexão de um dos cenários utilizando o tunelamento 6to4 e
com todos os agentes possíveis é apresentado na figura abaixo:
Cliente
TRÁFEGO IPV6 IPv6
NATIVO
Nativo
IPv6
TRÁFEGO 6to4
(IPv6 encapsulado
com protocolo 41)
Cliente
IPv4 RELAY/ROTEADOR IPv6
1 6to4 Nativo
Cliente
6to4 1
TRÁFEGO IPV6
NATIVO
ROTEADOR (GLOBAL- prefixo 6to4)
6to4
WAN IPv4 e IPv6 (6to4)
LAN IPv4 e IPv6 (6to4)
IPv6/IPv4 TRÁFEGO IPV6
NATIVO
(Pilha-Dupla) (LINK LOCAL fe80::/10)
Cliente
6to4
Cliente (podendo possuir um endereço IPv4
6to4
(podendo possuir um endereço IPv4
Figura 3.15 – Estrutura da conexão 6to4

61. 44
Os possíveis hosts que fazem parte desse cenário serão explicados abaixo:
• Roteador 6to4: equipamento com suporte ao tipo de tunelamento
6to4, que faz o papel de gateway para uma rede IPv6 nativa, caso
esta tenha necessidade de alcançar outra rede IPv6;
• Cliente/Roteador 6to4: este cliente possui um endereço IPv4
público e suporte ao túnel 6to4 através de interface virtual,
necessitando apenas de um relay 6to4 para acesso a uma rede IPv6
pura. Diferentemente do cliente 6to4, ele gera seu próprio endereço
6to4 através de seu IPv4 válido. Esse agente não terá, neste
trabalho, um cenário específico para ele, pois suas funcionalidades e
possibilidades de aplicação serão incluídas dentro do agente
Roteador 6to4;
• Cliente 6to4: cliente que possui endereço IPv6 no formato 6to4, mas
que pode ser obtido através de RA emitido pelo roteador 6to4 e
assimilado como se fosse um endereço IPv6 normal, mas com a
diferença de que esse endereço IPv6 vai possuir o prefixo
2002:aabb:ccdd:: pois adquire o prefixo do Roteador 6to4 montado
com o IPv4 válido do roteador. Pode ser utilizado com pilha dupla
para também possuir um endereço IPv4 local. Necessita de um
Roteador 6to4 para acesso à rede IPv6 puras e 6to4;
• Relay 6to4: roteador com suporte a 6to4 e IPv6 de puro,
possibilitando assim se comunicar com todos os segmentos (IPv6,
6to4 e IPv4).
Como cenário inicial, tem-se a comunicação de dois clientes 6to4 em redes
diferentes, interligados pela Internet (IPv4). Os clientes 6to4, apesar de
apresentarem o prefixo 2002:aabb:ccdd:: das redes 6to4, podem ser vistos
como estações que possuem IPv6 puras, pois o endereço desses clientes
foram obtidos através do RA emitido pelo Roteador 6to4, e os campos
“aabb:ccdd” não foram gerados internamente por seus IPv4’s. Para isso, a
figura abaixo mostrará o layout desse cenário específico, incluindo, para melhor
entendimento, a tabela de roteamento dos equipamentos envolvidos:

62. 45
Figura 3.16 – Comunicação do túnel 6to4
Equipamento Rota
Cliente 1 ::/0 (default IPv6) por R1
2002:0102:0304:1::/64 através da interface LAN
Roteador 1 ::/0 (default IPv6) pelo relay 6to4 e pela interface virtual 6to4 que neste
cenário não será utilizado
2002::/16 pela interface virtual 6to4
2002:0102:0304:1/64 rota para a LAN
Cliente 2 ::/0 através de R2
2002:0102:0305:1:/64 para a rede local através da interface LAN
Roteador 2 ::/0 através do relay 6to4 utilizando a interface virtual 6to4 (Rota não
utilizada neste cenário)
2002::/16 através da interface Virtual 6to4
2002:0102:0305:1:/64 para a rede local através da interface LAN
a) O pacote no exemplo acima é originado na rede IPv6 local (com prefixo
6to4) e enviado pela rota padrão para o roteador R1; analisando a tabela
de roteamento, nota-se que o pacote é enviado através da rota default
IPv6 (::/0) para o roteador R1;
b) O pacote IPv6 é recebido por R1 através da interface LAN; R1 verifica
sua tabela de roteamento e descobre que deve enviar o pacote para a

63. 46
sua interface virtual 6to4 (rota para rede 2002::/16); nesta interface, o
pacote IPv6 é encapsulado em um pacote IPv4 (protocolo tipo 41) que é
endereçado ao roteador R2 (endereço extraído do endereço IPv6 do
destinatário do pacote original);
c) O pacote IPv6 encapsulado em IPv4 é recebido por R2, através da sua
interface IPV4 ou WAN; como o pacote é do tipo 41, ele é encaminhado
à interface virtual 6to4, que o desencapsula; consultando a sua tabela de
roteamento, R2 descobre que o pacote é destinado à sua rede local
2002:0102:03:05:1::/64 (6to4), sendo assim, ele encaminha, através da
sua rede local, o pacote IPv6 ao computador C2.
d) O pacote retorna percorrendo o mesmo caminho e é analisado de forma
semelhante aos processos descritos nos itens a,b e c.
Note que o encapsulamento e desencapsulamento com o protocolo 41 é
feito somente nas bordas da rede, ou seja, nos Clientes 6to4 para o Roteador
6to4 ou até mesmo numa comunicação interna (na mesma rede) entre Clientes
6to4, onde os pacotes saem de suas respectivas interfaces como IPv6 puros
sem nenhum tipo de encapsulamento, sendo eles de escopo global ou link-
local.
3.2.2.2.1 Comunicação Cliente 6to4/Roteador 6to4 com Servidor IPv6
Nativo
Neste cenário será descrita a comunicação de um cliente 6to4 / Roteador
6to4 com um servidor IPv6 nativo, considerando a hipótese mais completa que
seria a utilização de um de dois relay’s 6to4, um para o tráfego de ida e outro
para o tráfego de volta.
A figura e a tabela de roteamento abaixo representam o envio de um pacote
IPv6 do cliente C2 para o servidor S2:

64. 47
Figura 3.17 – Comunicação relay/roteador 6to4 com servidor IPv6
Equipamento Rota
Relay 1 ::/0 rede IPv6 através da interface LAN
2002::/16 através da interface virtual 6to4
Relay 2 ::/0 rede IPv6 através da interface LAN
2002::/16 através da interface virtual 6to4
Servidor 2 Rota padrão através de R3
Roteador 3 2002::/16 através do relay RL2 (rota descoberta através da divulgação
via BGP)
Roteador 1 ::/0 através do relay 6to4 RL1 ou RL2 utilizando a interface virtual
6to4
2002::/16 através da interface virtual 6to4
2002:0102:0304:1/64 para a rede local através da interface LAN
Cliente 1 ::/0 através de R1
2002:0102:0304:1::/64 através da interface LAN
Cliente 2 ::/0 através de R1
2002:0102:0304:1::/64 através da interface LAN

65. 48
a) De acordo com a tabela de roteamento acima, o pacote será enviado
através de sua rede local IPv6 para o roteador R1, utilizando sua rota
default ::/0;
b) O pacote IPv6 é recebido pelo R1 através da interface LAN, que, por sua
vez, verifica em sua tabela de roteamento para onde deve enviar,
descobre que o pacote deve ser enviado para a interface virtual 6to4
(rota para rede 2002::/16); nesta interface o pacote IPv6 é encapsulado
em um pacote IPv4 (protocolo tipo 41) e enviado ao relay RL1 ou RL2 (o
relay 6to4 pode ser definido manualmente no roteador 6to4, ou então,
automaticamente através da utilização do endereço Anycast
192.88.99.1); neste caso, vamos supor que o pacote tenha sido enviado
para o relay RL1;
c) RL1 recebe o pacote 6to4, através da interface IPv4, verifica que o
pacote utiliza o protocolo 41 e faz o encaminhamento para a interface
virtual; esta, por sua vez, desencapsula o pacote IPv6 e verifica em sua
tabela de roteamento que deve enviá-lo pela interface LAN através do
roteador R3, que, por sua vez, repassa o pacote IPv6 ao servidor S2;
d) S2 responde o pacote com o envio de outro pacote IPv6 com destino ao
Cliente C2, utilizando a sua rota padrão que aponta para o roteador R3;
o roteador R3, por sua vez, recebe o pacote e, através da rota recebida
via protocolo BGP, ele sabe que deve enviá-lo para o relay mais
próximo, sendo o RL2, neste caso;
e) RL2 recebe o pacote IPv6 e verifica que o destino é a rede 6to4
(2002::/16); deste modo, de acordo com tabela de roteamento, ele deve
encaminhar o pacote para a interface virtual 6to4, que, por sua vez
empacota em um pacote IPv4 (protocolo 41) e envia ao endereço IPv4
que está implícito no endereço IPv6 do destinatário do pacote;
f) O roteador R1 recebe o pacote através de seu endereço IPv4, verifica
que o pacote está utilizando o protocolo 41 e o encaminha à interface
virtual 6to4; esta o desencapsula e verifica o endereço de destino; de

66. 49
acordo com sua tabela de roteamento e o endereço de destino, o pacote
IPv6 é enviado através da sua interface LAN para o Cliente 6to4 C2.
3.2.2.2.2 Segurança e Limitações do Túnel 6to4
O tunelamento do tipo 6to4 não suporta NAT, ou seja, o host que tiver
uma interface virtual 6to4 (em cima de uma rede IPv4) deverá,
obrigatoriamente, possuir um endereço IPv4 válido na Internet, sem qualquer
tipo de NAT, nem mesmo o simétrico. Isso gera alguns problemas, pois, para
se ter suporte ao 6to4, os equipamentos de borda (que, muitas das vezes, são
apenas CPE soho) tem que possuir suporte nativo ao tunelamento 6to4, além
de possuir um endereço IPv4 válido, e grande parte desses CPE’s só
suportariam essa nova tecnologia em sua interface externa com atualizações
de firmware do fabricante.
Em relação à segurança, dois aspectos devem ser observados de forma
mais criteriosa, pois eles são responsáveis pela maioria das brechas:
1) Os pacote IPv4 vindos de qualquer outro roteador 6to4 ou relay são
desencapsulados, sem exceção a regra, por todos os roteadores 6to4;
2) Hosts que possuem IPv6 puro enviam pacotes sem nenhuma restrição à
relays e roteadores 6to4;.
3) A montagem dos endereços IPv6 é realizada com os endereços IPv4
públicos dos clientes 6to4 e isso gera uma certa “falta de controle” em
relação aos endereços e à entrada da Internet IPv6 (exemplo: usuário
residenciais).
Essas brechas implicam em aberturas na segurança, sendo vulneráveis
a ataques do tipo Man-in-the-Middle e DoS , já que a não verificação dos
pacotes 6to4 em seus respectivos hosts permite que eles sejam incluídos em
um tráfego, sem a garantia de que os endereços existentes nos cabeçalhos
IPv4 e IPv6 sejam ou não verdadeiros. Essas brechas, por sua vez, devem ser
contornadas com filtragem do protocolo 41 como no ISATAP. Para maiores
informações sobre a segurança no túnel 6to4, pode ser consultada a RFC
3964.

67. 50
3.2.2.3 Túnel Broker
Descrito na RFC 3053 e sendo um das técnicas mais populares na
comunidade IPv6, permite que hosts IPv6/IPv4 isolados em uma rede IPv4, ou
até mesmo redes LAN IPv4 inteiras acessem redes e hosts IPv6. O túnel
Broker é uma forma de tunelamento simples, semelhante ao 6to4, porém com
algumas diferenças que, para os administradores de rede (público-alvo deste
trabalho), são de grande importância e que serão discutidas mais adiante.
Primeiramente, é necessário cadastrar-se em um provedor de acesso túnel
Broker (utilizamos neste trabalho o Broker Freenet6 encontrado no site
www.freenet6.com) para adquirir usuário e senha. Diferentemente do 6to4, é
necessário realizar o download de um software cliente, ou script de
configuração, que servirá para conectar com o túnel e se autenticar, receber as
configurações necessárias e montar o túnel. Os elementos principais utilizados
nessa topologia são:
• “Tunnel Broker”, abreviado “TB”, é o servidor responsável por receber as
requisições de túnel dos clientes e suas autenticações; o TB também é
responsável por fazer a troca dos endereços IPv6 e IPv4 entre o Tunnel Server
e o Broker Client para o fechamento do túnel; pode estar separado,
fisicamente, do Tunnel Server ou não;
• Tunnel Server abreviado, “TS”, é o servidor que fecha o túnel com o
Broker Client, fazendo o interfaceamento entre a Internet IPv6 com a Internet
IPv4 (onde encapsula os pacotes IPv6); pode estar ou não separado
fisicamente, do túnel Broker;
• Broker Client, abreviado “BC”, é o cliente do Broker que faz a requisição
do túnel para acesso à Internet IPv6.
Estes elementos e suas interações estão bem detalhados na figura abaixo:

68. 51
Figura 3.18 – Comunicação túnel Broker
Apesar de diversos cenários serem possíveis, como por exemplo, um único
computador pode acessar ao serviço de tunelamento do Broker (um assinante
residencial de Internet), o contexto utilizado, aqui neste trabalho, engloba os
diversos cenários usuais. Estes cenários também foram utilizados para os
testes no laboratório.
A figura abaixo representa o processo de inicialização do Broker e sua
descrição detalhada se encontra a seguir:

69. 52
SERVIDOR
WEB
TUNEL IPv6 NATIVO
TUNEL SERVER (TS) INTERNET IPv6
BROKER (TB)
5
R1
ROTEADOR IPv6
2
TUNEL
INTERNET (IPv6 encapsulado
3 IPv4 com protocolo 41)
14
1
ROTEADOR
(BC)
WAN IPv4 e IPv6 (Broker)
LAN IPv4 e IPv6 (Broker)
LAN IPv6/IPv4
5
(Pilha-Dupla)
6
Estação 2
IPv4/IPv6
Estação 1 (Pilha-Dupla)
IPv4/IPv6
(Pilha-Dupla)
Figura 3.19 – Inicialização do túnel Broker
1) O roteador de borda do cliente, que possui o autenticador do Broker
(BC), envia um pacote por sua rota IPv4 (Internet IPv4), autenticando-se
e requisitando serviço de túnel para o Broker (TB);
2) O TB envia um pacote ao Tunnel Server (TS), indicando o endereço
IPv4 do BC (outra ponta do túnel) e o endereço IPv6 que o BC utilizará
para ser adicionado em sua tabela de roteamento;
3) O TB envia um pacote para BC, indicando o endereço IPv4 e IPv6 do TS
para que se feche o túnel entre os dois pela Internet IPv4, utilizando o
protocolo 41; o BC utiliza esses parâmetros recebidos para também
alterar sua tabela de roteamento;
4) O túnel é, então, estabelecido entre o BC e o TS, que utilizaram o
protocolo 41 para encapsularem os pacotes IPv6 ao serem enviados
eles pela Internet IPv4; o protocolo é utilizado tanto para o TS quanto
para o BC;

70. 53
5) A partir deste ponto as estações da LAN podem utilizar o prefixo (obtido
por RA do BC) e auto-configurar seus endereços IPv6 de escopo global
para que possam se comunicar com o servidor WEB IPv6 como se
estivessem conectados ao backbone IPv6;
6) Toda a comunicação interna em IPv6 da LAN continua a ser realizada
normalmente pelo endereço “FE80::/10” de escopo link-local
possibilitando seu uso juntamente com o cenário de pilha-dupla
(IPv4/IPv6) e todos os recursos e serviços IPv6 disponíveis.
A conexão do túnel pode ser estabelecida através de NAT, diferentemente
do 6to4, já que a conexão pode ser totalmente configurada, e podem ser
utilizados pacotes UDP ao invés de pacotes TCP.
No laboratório o túnel Broker foi utilizado de forma concomitante com a
dual-stack nos hosts internos de uma LAN, pois o endereço obtido por RA
pelos hosts que utilizam o dual-stack (IPv4 nativo/IPv6 nativo) provém de
pacotes RA’s gerados pelo roteador de borda com endereço fornecido pelo
túnel Broker, e é interpretado pelos hosts internos como sendo o prefixo de
link-global IPv6 nativo.
O tunelamento via Broker foi o tunelamento utilizado neste trabalho como
link de saída IPv6 válido no laboratório, assim como seu prefixo através do RA
gerado pelo roteador de borda (cliente Broker), foi utilizado também pelas
estações para a geração de seus endereços individuais (estações que
possuem a pilha dupla).
3.2.2.3.1 Segurança Túnel Broker
Para a análise das falhas de segurança do túnel Broker devem ser tratadas
duas áreas em separado, que, juntas, fecham o serviço de túnel. Essas áreas
possuem dois elementos distintos e a segurança deve ser analisada na
interação entre eles: Interação Cliente - túnel Broker e Interação túnel Broker -
DNS.

71. 54
1) Para a Interação Túnel Broker – DNS: as falhas são tratadas na seção
DNSv6 em relação à atualização dinâmica do DNS e não serão
abordadas aqui.
2) Para a Interação Cliente – Túnel Broker: uma das falhas possíveis é o
problema de autenticação (usuário e senha) do cliente para ter acesso
ao Broker. Essa autenticação pode ser mais bem assegurada utilizando-
se de recursos como SSL para autenticações HTTP ou
preferencialmente, a utilização de um AAA (Radius) reforçando, assim, o
controle de acesso.
Outro problema possível é a ocorrência de um ataque do tipo DDoS que
ocorreria se um cliente malicioso abrisse indefinidamente sessões de túnel com
o Broker, causando assim a indisponibilidade do serviço. Esta situação é
facilmente resolvida limitando a quantidade de túneis que um determinado
usuário pode abrir ao mesmo tempo.
Outra situação é quando o usuário de uma conexão discada é
desconectado sem mandar o encerramento da conexão para o Broker. O
tráfego IPv6 continua sendo mandado pelo Broker para o IPv4 do cliente e, no
caso, esse IP pode não ser mais do mesmo cliente (foi remanejado para outro
assinante dial-up, por exemplo). Em suma, o Broker continua enviando o
tráfego IPv6 para um cliente qualquer, que pode aproveitar isso de forma
maliciosa. A solução para esta situação é a implementação de controle do tipo
“keep-alive” pelo cliente, de forma a manter o Broker informado de que o túnel
ainda está no ativo.
Outro problema, mas isso já faz parte mais especificamente do sistema
operacional do cliente, é a utilização de scripts fornecidos pelo Broker para sua
inicialização, alteração de DNS e tabela de roteamento, autenticação e
manutenção do túnel (keep-alive). Esses scripts geralmente são executados
com permissão de administrador ou superusuário, o que pode abrir falhas de
segurança no sistema do cliente.
Apesar de todos os problemas discutidos, ainda assim é a melhor
alternativa para os administradores por algumas razões:

72. 55
a) Diferentemente do 6to4, ele pode requerer (geralmente requer e isso é
bom) autenticação, pois a falta da mesma pode gerar certos tipos de
“abuso”;
b) A inicialização e montagem do túnel pode ser automática ou manual,
diferentemente da 6to4 que é automática;
c) Facilidade de gerenciamento dos parâmetros em comparação com
outras tecnologias de túnel (ideal para redes gerenciadas);
d) Possui possibilidade de uso tanto com NAT como sem ele (IPv4
público).
Porém, existe uma deficiência em relação ao volume de tráfego, pois o túnel
Server concentra toda entrada de tráfego para o mundo da Internet IPv6 por
ele, diferentemente das outras tecnologias de túneis disponíveis. Não quer
dizer que essa é uma característica ruim, porém em alguns casos, Brasil como
exemplo, onde não se possuem localmente os TS para se acessar uma página
em IPv6 dessa localidade, o tráfego deverá percorrer todo o caminho até o
Broker, que pode estar do outro lado do planeta, e retornar até o site em
questão, e sua resposta deverá fazer o mesmo caminho de volta, podendo
gerar um atraso.
3.2.2.4 Túnel Teredo
Na brecha deixada pelo tunelamento 6to4 e pelo túnel Broker tem-se essa
nova tecnologia de túnel, chamado Teredo, que funciona através do protocolo
UDP e permite o seu funcionamento através de NAT e sem autenticação. Essa
técnica não é eficiente, pois sua complexidade exige muito processamento,
mas, é uma das únicas formas de conexão para clientes que estão atrás de
NAT, seja ele do tipo Cone Full ou Cone restrito (não funciona através de NAT
do tipo Simétrico) e desejam se conectar a Internet IPv6 independente do
administrador de Rede e sem autenticação com um túnel Broker.
Apesar de essa técnica ser tratada neste trabalho como uma brecha de
segurança para o administrador de rede e uma migração segura (foco o
trabalho), ela será explicada, pois terá uma grande importância para a

73. 56
migração IPv4/IPv6 no âmbito do uso residencial, já que, neste segmento, não
existe a figura do administrador de rede e a segurança fica a cargo do próprio
usuário. O grande empecilho, no entanto, é que os servidores Teredo, são
definidos para descartar pacotes provenientes de NAT - Simétricos. Na RFC
4380 é mencionada a questão. “1) Clients located behind a symmetric NAT will
only be able to use Teredo if they can somehow program the NAT and reserve
a Teredo service port for each client, for example, using the DMZ functions of
the NAT. This is obviously an onerous requirement, at odds with the design goal
of an automatic solution. However, measurement campaigns and studies of
documentations have shown that, at least in simple "unmanaged" networks,
symmetric NATs are a small minority; moreover,it seems that new NAT models
or firmware upgrades avoid the "symmetric" design.” “…2) If the UDP packet is
not a Teredo bubble or an ICMPv6 message, it SHOULD be discarded… “
Apesar de ter sido citado no parágrafo acima que a “minoria dos
equipamentos” fazem o NAT do tipo simétrico, as marcas de CPE’s aqui do
Brasil (D-Link, Linksys, Netgear, NEC, entre outros) fazem esse tipo de NAT, o
que impossibilita a comunicação para a Internet IPv6 através do tunelamento
Teredo, salvo a orientação colocada na RFC 4380 para a utilização da função
“DMZ”, que alguns CPE’s possuem. Outro CPE como, por exemplo, no caso da
marca D-Link, possui uma opção referente ao NAT Simétrico, mas não de
forma explícita. Neste caso em específico (D-link modelo DI-524), deve-se
utilizar a opção para se desabilitar o NAT Simétrico e utilizar o NAT do tipo
Cone-Full, habilitando suporte à opção “XBOX Suporte” na aba tools na opção
misc. Em suma, para obter suporte ao NAT Cone-Full, o CPE deve possuir
esse suporte nativo no firmware fornecido pelo fabricante.
Outra observação citada acima é a forma como os servidores Teredo
devem agir, caso os pacotes não sejam do tipo ICMP ou participantes do túnel
Teredo (como os do tipo NAT-Simétrico), sendo requisitado que os servidores
realizem os descartes. Essas medidas foram amplamente discutidas em sites e
em fóruns, inclusive do próprio IETF. O NAT-Simétrico, no início do
desenvolvimento do Túnel Teredo era até permitido em seu funcionamento,
sendo verificado mais tarde que ele causava um aumento no processamento
do Servidor Teredo, podendo causar indisponibilidade ou lentidão em seu

74. 57
serviço. Assim, o suporte ao NAT-Simétrico foi retirado, pois se imaginava um
cenário onde poucos servidores Teredo existiriam para suprir os túneis para
todos os clientes Teredo da Internet. Exemplo é a discussão no IETF: “… As
Pekka pointed out, the traversal of symmetric NAT could easily be added to
Teredo. It was in fact supported in the early drafts. It was removed later in an
effort to avoid overload on the servers, in a deployment scenario where there
are just a few Teredo servers for the entire Internet
Uma nova implementação de tunelamento para ser utilizada junto com os
diversos tipos de NAT está sendo desenvolvida pela IETF, mas existe ainda
apenas como draft (draft-liumin-v6ops-silkroad-02.txt) e se chama SilkRoad.
Para a técnica de tunelamento Teredo, o túnel é fechado diretamente da
máquina do cliente, ou seja, sem a necessidade de um túnel-gateway, sendo
que a comunicação existe, basicamente, entre o cliente, relay e servidor
Teredo. Para tanto, o NAT-gateway não pode causar “interferência” na
comunicação, e isso é obtido na figura abaixo:
Figura 3.21 – Configuração Teredo

75. 58
1. Como início do processo, o cliente Teredo precisa determinar que tipo
de NAT o gateway está utilizando para dar o acesso à Internet IPv4 e,
então, o cliente envia uma mensagem de RS com destino ao IP primário
(IPv4) do servidor Teredo, que necessita possuir dois endereços IPv4
públicos (primário e secundário). A resposta ao RS do cliente é um RA,
mas, como o pacote RS do cliente veio com a flag do NAT tipo Cone
ativado (atribuído pelo próprio cliente), o endereço de origem deste
pacote RA gerado como resposta pelo servidor Teredo é com seu
endereço IPv4 secundário. Dessa forma, verificando esse endereço
secundário no pacote RA, o cliente consegue determinar que o tipo de
NAT atrás do qual ele se encontra é do tipo Cone Full
2. Caso o pacote RA, enviado pelo servidor Teredo, não tiver sido
recebido, o cliente Teredo envia outro pacote RS sem a marcação da
flag “Cone” no pacote. O servidor Teredo, então, este novo RS e verifica
que a flag está, dessa vez, desmarcada. Em conseqüência, ele
responde com um pacote RA, mas com o endereço de origem como
sendo seu endereço IPv4 primário. O cliente, recebendo esse novo
pacote determina que ele esteja atrás de um NAT do tipo Cone Restrito;
3. O Cliente, então, faz o último teste, que é a verificação de que ele não
está atrás de um NAT do tipo simétrico, pois o mesmo é incompatível
com o tunelamento Teredo. Para tanto, o cliente manda novamente para
o servidor Teredo um pacote RS, mas como destino o endereço IPv4
secundário do servidor Teredo. O servidor, por sua vez, responde à
requisição com um pacote RA e, no momento em que o cliente recebe
este pacote, ele verifica os campos de endereço e porta UDP de origem
e compara-os com o pacote RA recebido com o endereço primário do
servidor Teredo. Caso os campos sejam diferentes nas mensagens o
cliente entende que está atrás de um NAT do tipo Simétrico e que o
tunelamento Teredo não tem possibilidade de ser utilizado. O
mapeamento das portas UDP no NAT é mantido por pacotes chamados
de “bubbles”, enviados pelo cliente para o servidor Teredo, que envia
uma resposta (com a periodicidade padrão de 30s) de forma a manter o

76. 59
mapeamento feito nas portas UDP do NAT-Gateway por todo o tempo
de conexão.
O endereço Teredo é formado por 5 campos distintos, e seu prefixo definido
pela IANA é 2001:0000. O primeiro campo é o próprio prefixo 2001:0000; o
segundo campo é o endereço IPv4 primário do servidor Teredo que enviou o
pacote de RA para o cliente; o terceiro é um campo de 32 bits utilizado para
“atribuição de flags”; mas somente o primeiro bit é utilizado e identifica o tipo de
NAT que o cliente se encontra (1 para NAT do tipo Cone-Full); o resto dos bits
desse campo ainda não possui definição, o que ocorrerá no futuro; no quarto
campo aparece a porta UDP de saída do NAT, mascaradas por inversão dos
bits (mascaramento necessário para evitar a substituição que alguns NAT’s
fazem das mesmas pelas portas públicas); e o quinto e último campo é o
endereço público do NAT-Gateway, também mascarado por inversão dos bits
para que o próprio não encontre endereços públicos ou privados e os altere.
Referentes à utilização do túnel Teredo serão considerados que a
comunicação é feita entre o cliente Teredo e um host IPv6 nativo. Também
será considerado que o host IPv6 nativo pode iniciar uma conexão com o
cliente Teredo e serão variados os dois tipos de NAT que o cliente pode estar
atrás: o tipo restrito e o tipo cone. O Cenário correspondente ao NAT do tipo
Cone estará implícito no cenário do NAT do tipo restrito, pois o mesmo se dá
pelo acréscimo de alguns passos, além do processo de comunicação do NAT
tipo cone, tornando-se uma forma mais “completa” e geral.
Referente ao NAT do tipo restrito, com o cliente Teredo iniciando uma
conexão com um host IPv6 nativo, temos os seguintes passos:

77. 60
Figura 3.22 – Conexão Teredo com NAT do tipo restrito
1. Depois de iniciado todo o procedimento de determinação do tipo de
NAT utilizado pelo NAT-Gateway de sua rede, o cliente precisa descobrir o
endereço IPv4 do relay Teredo; para obter isso o Cliente envia uma
mensagem ICMPv6, através do servidor Teredo, para o host IPv6 nativo;
2. O host IPv6 nativo manda um pacote de reposta ICMPv6 (reply) ao
cliente Teredo que havia feito a requisição (request), enviando o pacote
pelo relay Teredo mais próximo;
3. Aqui inicia a diferença entre o NAT Restrito e o NAT tipo Cone; para o
tipo Cone basta, simplesmente, ir diretamente ao passo 8 deste passo-a-
passo; para o tipo restrito, e através do pacote ICMPv6 recebido, o relay
verifica que o cliente Teredo está atrás de um NAT do tipo restrito e que, se
tentar uma conexão direta com ele através do NAT-Gateway, seus pacotes
serão descartados devido a inexistência de uma mapeamento de portas

78. 61
referente ao tráfego Teredo no NAT-Gateway; o relay guarda o ICMPv6
(reply) em sua fila para uma comparação posterior e, então, envia um
pacote “bubble”, tendo como destino o cliente Teredo, através do servidor
Teredo (que já possui uma conexão aberta para o cliente Teredo pelo NAT);
4. De posse do pacote “bubble”, o servidor Teredo o encaminha para o
cliente Teredo, mas trocando o endereço e porta de origem do pacote
“bubble”, colocando o endereço e a porta do relay Teredo no campo origem
do pacote; com isso o pacote atravessa o NAT-Gateway e chega ao cliente
Teredo
5. De posse do pacote, o cliente Teredo envia para o endereço de origem
e porta (relay Teredo) um pacote “bubble” para o relay Teredo para que o
NAT-Gateway de sua rede abra um mapeamento de porta para o túnel
Teredo no NAT;
6. Ao receber o pacote “bubble” enviado pelo cliente Teredo, o relay
Teredo descobre que ele pode corresponder, agora diretamente, com o
cliente Teredo através do NAT Restrito, com base no endereço obtido no
pacote “bubble” recebido do Cliente Teredo e comparando-o com o pacote
ICMPv6 que ele havia guardado na fila;
7. O relay Teredo manda, então, o pacote ICMPv6 que ele havia guardado
para o Cliente Teredo, demonstrando para o cliente que o túnel Teredo com
a Internet IPv6 já está operacional pelo NAT e que o host IPv6 nativo já é
alcançável;
8. Depois de recebido o pacote, o Cliente Teredo inicia e sua comunicação
diretamente com o host IPv6 nativo, utilizando sempre o relay Teredo como
gateway entre o túnel Teredo e a internet IPv6.
3.2.2.4.1 Segurança do túnel Teredo
O principal problema de segurança apresentado pelos túneis Teredo é o
fato do tráfego poder passar despercebido pelos filtros e firewalls se os
mesmos não estiverem preparados para interpretá-lo. Sendo assim, os
computadores e a rede interna ficam totalmente expostos aos ataques vindos

79. 62
da Internet IPv6. Para resolver este problema, antes de implementar o Teredo,
é necessário que se faça uma revisão nas regras dos filtros e firewalls da rede,
ou, ao menos, nos computadores que utilizarão esta técnica. Além deste
problema, ainda é possível observar os seguintes:
a) O cliente Teredo divulga, na rede, a porta aberta por ele no NAT e o tipo
de NAT que ele está utilizando, possibilitando assim um ataque através
dela;
b) A quantidade de endereços Teredo é bem menor que os de IPv6
nativos, facilitando assim a localização de computadores vulneráveis
através de address scanning;
c) Um ataque por negação de serviço é fácil de ser aplicado tanto no
cliente quanto no relay;
d) Devido ao método de escolha do relay pelo host de destino, pode se
criar um relay falso e utilizá-lo para coletar a comunicação deste host
com os seus clientes (ataques Man-in-the-Middle).
Esses tipos de ataques são difíceis de serem impedidos, caso o invasor não
tenha atitudes diferentes das permitidas no NAT. Entretanto, é possível atenuar
este problema com atitudes como: implementar servidores Teredo
redundantes, utilizados em caso de "queda" por negação de serviço; utilizar
firewalls e filtros de pacotes; e utilizar os serviços de segurança do IPv6, como
IKE, AH, ou ESP.
O Teredo já vem instalado e ativo por padrão em alguns OS como por
exemplo, o Windows Vista e o 2008 Server, ao contrário do Linux e do
FreeBSD.
3.2.2.4.2 Problemas com Túneis:
Alguns problemas de comunicação devem ser tratados pelo host de
entrada do túnel. É preciso determinar quando fragmentar o pacote ou quando
reportar ao host de origem um erro ICMPv6 "packet too big", além de traduzir
erros ICMPv4, reportados pelos roteadores ao longo do caminho do túnel, em

80. 63
erros ICMPv6 e transmiti-los de volta ao host de origem. O primeiro problema,
remete à implementação de Static Tunnel MTU ou Dynamic Tunnel MTU,
informações podem ser obtidas através da RFC 4213. O segundo depende do
modo como o roteador devolve a mensagem de erro, visto que roteadores mais
antigos retornam apenas 8 bytes de dados, além do cabeçalho IPv4, o que não
é suficiente para incluir o campo de endereço do cabeçalho IPv6. Entretanto,
roteadores mais novos, são capazes de retornar além do cabeçalho IPv4, os
dados do cabeçalho IPv6, permitindo ao host encapsulador extrair o pacote
IPv6 encapsulado, e usá-lo para gerar uma mensagem ICMPv6, direcionando-a
para o host IPv6 de origem.
Interessante ressaltar, que as técnicas de tunelamento são tratadas pela
camada IPv6 como um modelo " single-hop ”, isto é, todo o trajeto entre origem
e destino do pacote IPv6 é visto como um único salto. Isto ocorre porque o
campo hop Limit do cabeçalho IPv6 só é decrementado no encaminhamento do
pacote e, assim, os hosts de entrada e saída do túnel não o decrementam.
3.3.3 Tradução
As traduções são técnicas utilizadas para permitir uma comunicação
entre hosts que são IPv4 puros, ou seja, que não possuem suporte a nenhuma
outra tecnologia IPv6, como os descritos acima, com hosts IPv6 também puros,
que não possuam endereço IPv4 ou suporte à pilha-dupla. A utilização de
tradutores pode ser considerado como um “remendo” e não uma técnica de
migração em si, pois consiste em utilizar um host como se fosse um roteador
(uma espécie de NAT-Gateway), roteando pacotes de uma “rede IPv4 pura”,
para uma “rede IPv6 pura”, mesmo que essa rede seja, por exemplo, uma LAN
de uma empresa rodando simultaneamente IPv4 e IPv6. Não se vê a
necessidade do uso e de desenvolvimento utilizando técnicas de tradução,
simplesmente pelo fato de que, no início, é improvável se ter um host que tem
obrigatoriadade de ser IPv6 puro em uma LAN, seja por falta de recurso do
mesmo, sem um mínino suporte à pilha-dupla. Todos os desenvolvedores,
softwares e fabricantes de equipamentos que suportem o IPv6 possuem
também suporte ao IPv4 e, assim, não têm, suportamente, problemas de se
comunicarem em IPv4 com um host “legado IPv4”. Entretanto, por se tratar de

81. 64
um dos métodos tratados na literatura, segue uma explanação dos principais
mecanismos.
3.3.3.1 Mecanismos de Tradução
3.3.3.1.1 Staless IP/ICMP Translation( SIIT)
O SIIT é definido como um mecanismo de tradução stateless de
cabeçalhos IP/ICMP, o qual permite a comunicação entre hosts com suporte
apenas ao IPv6 com os hosts que apresentam suporte apenas ao IPv4. É
utilizado um tradutor localizado na camada de rede da pilha, que converte
campos específicos dos cabeçalhos de pacotes IPv6 em cabeçalhos de
pacotes IPv4 e vice-versa. Para realizar este processo, o tradutor necessita de
um endereço IPv4-mapeado-em-IPv6, no formato 0::FFFF:a.b.c.d, que
identifica o destino IPv4, e um endereço IPv4-traduzido, no formato
0::FFFF:0:a.b.c.d, para identificar o host IPv6. Quando o pacote chega ao SIIT,
o cabeçalho é traduzido, convertendo o endereço para IPv4 e encaminhando
ao host de destino (RFC2765, 2000).
3.3.3.1.2 Network Address Translation with Protocol Translation
(NAT/NAPT-PT)
É um mecanismo que permite a comunicação de hosts IPv6 com hosts
IPv4, que combina métodos de tradução de cabeçalho e conversão de
endereço (RFC2766, 2000). O funcionamento do NAT-PT/NAPT-PT acontece
da seguinte forma:
Um host IPv6 envia um pacote ao gateway NAT-PT/NAPT-PT, que
mapeia o endereço do host para um endereço IPv4 público, traduzindo o
protocolo IPv6 para IPv4, e envia o pacote ao host IPv4 de destino. Ao enviar o
pacote ao gateway, o host IPv6 vai adicionar um prefixo pré-configurado ::/96
ao endereço IPv4 do destino, tendo em vista que o gateway só aceita pacotes
identificados com esse prefixo. A partir desse endereço, será obtido o endereço
real do destino, eliminando o prefixo IPv6 de identificação. Em sua
configuração padrão, o NAT-PT é unidirecional, ou seja, apenas hosts IPv6
podem iniciar a sessão. No entanto, é possível torná-lo bidirecional,

82. 65
desenvolvendo um gateway DNS-Application Level Gateway (DNS-ALG)
(RFC2766, 2000).
3.3.3.1.3 Network Address Port Translation and Packet Translation
(NAPT-PT)
É um mecanismo que possibilita, de forma nativa, que host IPv6 possam
comunicar com hosts IPv4, e vice e versa. É estabelecido na fronteira entre um
host IPv6 e IPv4 e utiliza apenas um endereço IPv4. Seu funcionamento
consiste em traduzir e identificar as portas TCP/UDP dos hosts IPv6 em porta
TCP/UDP do endereço IPv4 registrado. Deste modo, enquanto no NAT-PT o
número de sessões limita-se a quantidade de endereços IPv4 disponíveis para
a tradução, no NAPT-PT é possível realizar 63.000 sessões TCP e 63.000
sessões UDP por endereço IPv4 (RFC2766, 2000). Um ponto fundamental
para utilização do NAT-PT é que ele só pode ser utilizado quando não houver
mecanismos de tunelamento.
Com a utilização dos mecanismos de “tunelamento” as chamadas
traduções não serão utilizadas ou quando forem serão utilizadas como
soluções paliativas.
3.3.4 Problemas Adicionais de Segurança em IPv6
3.3.4.1 Roteamento
Em uma rede IPv6/IPv4, a configuração do roteamento IPv6 normalmente é
independente da configuração do roteamento IPv4. Isto implica no fato de que,
se a rede antes de ser implementada a pilha dupla utilizava apenas o protocolo
de roteamento interno OSPFv2, com suporte apenas ao IPv4, será necessário
migrar para um protocolo de roteamento que suporte tanto IPv6 quanto IPv4,
como IS-IS por exemplo, ou forçar a execução de um IS-IS ou OSPFv3
paralelamente com o OSPFv2.
3.3.4.2 Router Advertisement e do Neighbor Discorvery
O Router Advertisement (RA), assim como o protocolo Neighbor

83. 66
Discovery (ND), estão diretamente sujeito da mesma maneira a 3 tipos básicos
de ataques: DoS e de Router e Address Spoofing (Man in the middle).
Os três ataques podem ser efetuados separadamente ou juntos, bastando
somente ao invasor utilizar as conseqüências de um ataque como recurso para
o outro. Uma forma possível de ataque desse tipo seria um host malicioso da
rede começar a mandar pacotes de RA contendo ele próprio como default
gateway da rede, assim como mandar pacotes construídos com os endereços
de origem dos roteadores legítimos da rede de forma a sinalizar para os
próprios roteadores que o campo Router Lifetime foi alterado para 0, forçando
com que todos os pacotes sejam, então, direcionados para o roteador “rougue”.
Essa falha pode ser associada a uma outra falha do protocolo ADDRCONF,
que não verifica se a origem do pacote RA realmente veio de um roteador que
tem domínio em relação ao prefixo da rede. Esse tipo de ataque não se
diferencia no IPv4 tendo em vista que, apesar de não existir pacote RA no
IPv4, um servidor DHCP malicioso pode mandar informações erradas de
configuração de IP (endereço do host, gateway padrão,...). A solução definitiva
para este problema é a utilização do IPSEC para a autenticação da origem dos
pacotes e das relações de confiança entre as máquinas.
3.3.4.3 DHCPv6
A falha de segurança do DHCPv6, apesar de a configuração do
endereço de IP não necessariamente depender dele (como no DHCPv4),
ocorre porque endereços de DNS e NTP, assim como outros tipos de serviços,
correm o risco de se utilizarem de servidores DHCPv6 maliciosos, fornecendo
configurações erradas para um cliente requisitante. Com as infomações
erradas, e dependendo da funcionalidade da máquina, inclusive um ataque
DoS pode ser executado, caso se junte endereços de DNS falsos com serviços
existentes na máquina.
E de forma semelhante às falhas apresentadas para os protocolos RA e
ND, o DHCPv6 estará sujeito a esse tipo de ataque, equanto não se utilizar
uma forma concisa de se saber a autenticidade do servidor, ou seja, por meio a
utilização do IPsec.

84. 67
3.3.5 Compatibilidade de Software, Sistemas Operacionais e
Hardwares (Firmwares)
Ao invés de apresentar marcas, produtos e suporte dos equipamentos e
sistemas operacionais ao IPv6, apresenta-se um programa oficial de suporte
IPv6 para equipamentos e sistemas operacionais, chamado de Fases do IPv6.
O Fórum Oficial do IPv6 ( www.IPv6forum.com ) possui um consórcio de
nível internacional para o desenvolvimento e migração de equipamentos e
softwares que terão suportes ao IPv6. Com isso, os fabricantes de hardware e
software podem se guiar no desenvolvimento e fabricação de componentes
que suportam nativamente a nova tecnologia IPv6.
No entanto, para todo o hardware e software já existente houve uma
necessidade de se criar uma forma padronizada de classificação de suporte ao
IPv6, onde equipamentos e softwares podem ser colocados em níveis
semelhantes de capacidade de operação e recursos disponíveis de IPv6. Com
essa finalidade, o IPv6 Fórum criou um comitê internacional chamado “IPv6
Ready Logo Commitee” ou “v6LC”. Esse comitê tem por responsabilidade
gerenciar o programa de certificação dos softwares e hardwares, dando a
concessão de uma logomarca para determinado nível de suporte ao IPv6, a
partir de testes realizados em laboratórios específicos. Esses laboratórios são:
TAHI Project (Japão), Universidade de New Hampshire InterOperability (UNH-
IOL-EUA), IRISA/INRIA (Franca), European Telecommunications
Standardization Institute ETSI (Europa), Telecommunication Technology
Association TTA (Korea), Beijing Internet Institute BII (China), ChungHwa
Telecom Labs CHT-TL (Taiwan) e Japan Approvals Institute for
Telecommunications Equipment JATE (Japao). Esse programa é conhecido
como “IPv6 Ready Logo Phase Series.
O programa IPv6 Ready Logo Phase Series é subdividido em três fases
(Fase 1, Fase 2 e Fase 3), indo de um suporte mínimo ao protocolo IPv6 (Fase
1), passando por um suporte mais completo ao protocolo e serviços (Fase 2)
até o Fase 3, que ainda não foi determinado os requisitos para a obtenção
desse nível de logo. Todos os requisitos necessários para a obtenção das

85. 68
Logomarcas estão apresentados no site, assim como atualizações são
realizadas constantemente nos requisitos, de forma que, para a manutenção da
Logomarca, todos os participantes devem sempre atender aos requisitos das
respectivas fases suportadas.
No site também são encontradas as listas (referentes à Fase 1 e Fase 2)
dos fabricantes e dos produtos de forma detalhada. Inclui suportes específicos
que não fazem parte dos requisitos para a obtenção das Logomarcas (como
por exemplo, suporte ao tunelamento 6to4) e o laboratório responsável pelos
testes e fornecimento do aval para que a empresa possa colocar a Logomarca
em seu produto.
3.3.5.1 Fase 1 - Silver Logo
Como primeira fase, funcional desde 1º de setembro de 2003, a
Logomarca indicará que o produto, previamente foi analisado nos laboratórios
certificados, possui suporte a recursos básicos do IPv6 e também tem a
capacidade de operar com outras implementações da Fase 1 e Fase 2. A Fase
1 é composta de 170 testes distintos dentro das capacidades do IPv6.
Figura 3.23 – Logo Silver Fase I
Os requisitos para a obtenção dessa Logo são:
a) Especificações “core”do protocolo IPv6 funcionando perfeitamente;
b) Suporte à Neighbor Discovery;
c) Suporte ao ICMPv6 (Internet Control Message Protocol versão 6);
d) Suporte à autoconfiguração (stateless address) do endereçamento de
rede.

86. 69
3.3.5.2 Fase 2 - Gold Logo
A Fase 2, funcional desde 16 de fevereiro de 2005, é uma expansão dos
requisitos necessários obtidos na Fase 1. Essa expansão está, basicamente,
na extensão dos testes, que são aumentadas de 170 para 450. A quantidade e
extensão dos testes para a Fase 2 é maior, pois são consideradas as partes
das RFC’s definidas pelo IETF que não possuem obrigatoriedade, mas que são
aconselháveis possuir.
Figura 3.24 – Logo Gold Fase 2
Os requisitos mínimos para a obtenção da logomarca fase 2 além do
que já são necessários para a obtenção da Logomarca Fase 1 são os suportes
à: IPsec, IKEv2, MIPv6, NEMO, DHCPv6, SIP, Gerenciamento (SNMP-MIBs),
MLD (ainda em desenvolvimento).
Abaixo são listados os tipos de produtos que podem adquirir o Phase 2 Logo:
• IPv6 Core Protocols
Host
Router
• IPsec
End-Node
Security Gateway
• IKEv2
End-Node
Security Gateway

87. 70
• MIPv6
Correspondent Node
Home Agent
Mobile Node
• NEMO
Home Agent
Mobile Router
• DHCPv6
Client
Server
Relay Agent
• SIP
SIP Server (Proxy and Registrar)
SIP User Agent
• Management (SNMP-MIBs)
Agent
Manager
Foram explicadas, neste capítulo, algumas das formas de coexistências
entre as duas versões do protocolo IP e o funcionamento destas interações. No
próximo capítulo serão tratados alguns dos possíveis cenários de topologias
referentes à migração, assim como a configuração dos equipamentos utilizados
no laboratório para a realização dos testes.

88. 71
4. CONFIGURAÇÕES DO AMBIENTE DE TESTE
Neste capítulo, serão descritos os cenários que impulsionam a migração
de IPv4 para IPv6, as configurações realizadas nos ativos do laboratório para
execução dos testes e será considerada a implantação dos serviços relevantes
à migração.
4.1 Cenários
Os cenários e os desenvolvimentos propostos a seguir consideram os
seguintes aspectos:
1) Os interessados neles são os administradores de rede do cliente e a
operadora de Telecom;
2) A abrangência interna (LAN) é de inteira responsabilidade do
administrador de rede do cliente;
3) A abrangência do Link Dedicado, roteadores do backbone e a interface
externa do roteador CPE são de inteira responsabilidade da operadora
de Telecom;
4) Toda a parte de tratamento dos dados assim como a tradução dos
endereços nas duas versões no backbone da operadora não fará parte
do escopo do trabalho;
5) O túnel Broker (exemplo: Freenet), que é utilizado para acesso externo e
que suporta o Link IPv6 do cliente, é de responsabilidade de terceiros, já
que não temos influências em seu funcionamento;
6) As configurações dos SO’s e equipamentos estão limitadas à interface
interna do CPE;
7) Todos os cenários são considerados como etapas de um processo
maior, que tem por objetivo migrar todos os hosts IPv4 para uma rede
IPv6 pura.

89. 72
A tabela a seguir representa as possíveis variações dos cenários em
relação ao domínio do administrador de rede (ADM) e da operadora de
Telecom (OP). As siglas “v6, v4 e v4v6” significam as interações utilizadas e
significam, respectivamente, IPv6, IPv4 e dual-stack IPv4/IPv6. Os números na
tabela denotam o número do cenário.
ADM v4 ADM v4v6 ADM v6
OP v4 0 3 6
OP v4v6 1 4 7
OP v6 2 5 8
Tabela 4.1 – Cenários para implantação de redes
O seguinte ambiente foi montado em laboratório para os testes dos
cenários apresentados. As configurações dos ativos foram alteradas para se
encaixarem em cada tipo de cenário e serão descritas em cada caso,
respectivamente.
Figura 4.1 – Ambiente de Laboratório.

90. 73
O ambiente montado no laboratório possui os seguintes equipamentos
sistemas operacionais.
Nome do ativo OS Versão IPv4 IPv6 Finalidade
Gandalf Linux 2.6.26 SIM SIM Roteador/Servidor/Firewall
Legolas iX Embedded Dlink XXXX SIM NÃO* Access-Point
Pippin ---------- -------- ----- ------- HUB
Aragorn iX Embedded 3Com SIM SIM SWITCH - GERENCIAVEL
Gimli iX Embedded HP SIM NÃO Impressora de rede
Frodo Linux 2.6 SIM SIM Desktop
Sam Linux 2.4 SIM SIM Desktop
Arwen Linux 2.6 SIM SIM Desktop/Sniffer
Faramir Windows Vista SIM SIM Desktop
Isildur Windows XP SP3 SIM SIM** Desktop
Tabela 4.2 – Configuração dos ativos
* Para suporte ao protocolo IPv6 é necessário upgrade de firmware do fabricante.
**Suporte parcial a serviços IPv6 (Não suporta DHCPv6).
4.1.1 - Cenário 0
O administrador utiliza IPv4 e a operadora fornece IPv4.
Este é um cenário mais utilizado hoje em dia, e mostra exatamente, a
situação que precede o início de uma migração. Este cenário considera que o
administrador utiliza, em sua rede, IPv4, e a operadora fornece também IPv4,
sendo a solução mais utilizada no funcionamento das redes e do backbone das
operadoras. Por decisão do administrador, configura-se a utilização de um
túnel Broker para ter acesso à rede IPv6 e, assim, prover acesso à rede IPv6
para sua LAN, através de um tradutor (4to6) configurado em seu CPE (Cliente
Provider Equipament). Sua configuração, neste caso, está baseada somente
no CPE.

91. 74
Figura 4.2 – Cenário 0 – Rede Interna e operadora IPv4 - túnel Broker IPv6
4.1.2 - Cenário 1
O administrador utiliza IPv4 e a operadora fornecerá IPv4 e IPv6 (dual-
stack).
Neste cenário, o ADM continua operando com sua rede v4 pura e a
operadora passa a fornecer v6 e v4, tendo que configurar um tradutor no CPE,
para que ele possa ter comunicação com as redes IPv6, tendo como origem as
máquinas internas IPv4, fazendo a tradução (4to6), de IPv4 para IPv6. O
administrador, neste caso, não fará nenhuma alteração em sua rede, mas terá
acesso aos sites/serviços IPv6 puros através da configuração (dual-stack) feita
em seu CPE pela operadora de Telecom.
Operadora
Telecom
DualStack
LAN IPv4/IPv6
TELECOM
CPE ROUTER
ROUTER
IPv6
IPv4

92. 75
Figura 4.3 – Cenário 1 – Rede Interna IPv4 e operadora IPv4 e IPv6 (dual-stack)
4.1.3 - Cenário 2
O administrador só utilizará IPv4 mas a operadora só poderá fornecer
IPv6.
Neste cenário, a operadora fornecerá para o cliente somente
endereçamentos IPv6 e deverá configurar, na interface externa do CPE, um
tradutor (4to6) para a rede IPv4 do cliente. A operadora terá, também, a
responsabilidade de fazer o tunelamento (6to4), caso o cliente deseje algum
site/serviços que seja IPv4 puro, e este seja externo ao backbone da
operadora. Neste caso será necessária a funcionalidade de um Broker dentro
da operadora de Telecom. Entretanto, consideramos que este é um cenário
futurista onde o link disponibilizado pela operadora fornecerá apenas IPv6 puro,
já que o processo de migração será gradativo e ainda existirão diversos
sites/serviços com acessos apenas em IPv4.
Figura 4.4 – Cenário 2 – Rede Interna IPv4 e operadora IPv6
4.1.4 - Cenário 3
O administrador inicia migração de sua rede IPv4 para IPv6 utilizando-se
do recurso de dual-stack e a operadora ainda fornece somente IPv4
Neste caso, a configuração de dual-stack da rede interna é de inteira
responsabilidade do administrador de rede. Ele também será o responsável

93. 76
pela configuração das rotas e contas para a utilização do túnel Broker IPv6, já
que a operadora fornecerá apenas endereços IPv4, e sua responsabilidade se
limita às rotas e configurações IPv4.
Para acesso aos sites IPv6, os hosts internos que possuírem dual-stack
configurados sairão pela rota obtida com o túnel Broker, e poderão ter acessos
aos sites IPv6 puros, assim como aos sites IPv4 puros. Os hosts internos que
são IPv4 puros só conseguirão acesso à rede IPv6 se o administrador
configurar um tunelamento no CPE para esses hosts. Esse cenário é montado
por iniciativa tão somente do administrador, visando preparar sua rede para o
futuro, quando a operadora passará a fornecer endereços IPv6, porém, nestas
circunstâncias, a configuração será transparente para a operadora de Telecom.
Figura 4.5 – Cenário 3 – Rede Interna IPv4 e IPv6 (dual-stack) e operadora IPv4
4.1.5 - Cenário 4
O administrador utiliza IPv6 e IPv4 em dual-stack enquanto a operadora
fornece IPv4 e IPv6 também em dual-stack.
Neste cenário, tanto o administrador quanto a operadora utilizam dual-
stack IPv4/IPv6 em suas redes. A responsabilidade de migração, neste caso, é
igualmente dividida entre as duas partes, e acontece sem a necessidade da
utilização de tradutores (4to6 ou 6to4), pois tanto a rede LAN quanto o CPE
terão os dois endereçamentos. Essa abordagem será a mais comum em uma
transição conjunta, já que os sites redes IPv4 continuarão a existir por um
longo período e serão criadas novas redes IPv6.

94. 77
Figura 4.6 – Cenário 4 – Rede Interna e operadora IPv4 e IPv6 (dual-stack)
4.1.6 - Cenário 5
O administrador utiliza IPv6 e IPv4 em dual-stack enquanto a operadora
fornece somente IPv6.
Neste cenário, a operadora fornecerá para o cliente somente
endereçamentos IPv6, e deverá configurar na interface externa do CPE um
tradutor (4to6) para a rede IPv4 do cliente. O administrador migrará sua rede e
fará uso da funcionalidade dual-stack. A operadora terá a responsabilidade de
fazer a tradução (6to4), caso o cliente necessite acessar sites/serviços que
sejam IPv4 puro, e esteja externo ao backbone da operadora, sendo
necessária a utilização de um Broker dentro da operadora de Telecom. Este,
no entanto, é também um cenário futurista, em que o backbone da operadora
opere apenas com IPv6 puro.
Figura 4.7 – Cenário 5 – Rede Interna IPv4 e IPv6 (dual-stack) e operadora IPv6

95. 78
4.1.7 - Cenário 6
O administrador utiliza somente IPv6 em sua rede e a operadora fornece
somente IPv4.
Neste cenário, a configuração IPv6 da rede interna é de inteira
responsabilidade do Administrador. Ele também é responsável pela
configuração das rotas e contas para a utilização do Broker IPv6, já que a
operadora fornecerá apenas endereçamentos IPv4 e sua responsabilidade se
limita às rotas e configurações IPv4. Para acesso aos sites/serviços IPv6 os
hosts internos sairão pela rota obtida com o túnel Broker e poderão ter acessos
aos sites IPv6 puros, assim como a redes IPv4, através de um tradutor (6to4)
configurado no CPE pelo Administrador. Esse cenário é montado por iniciativa
tão somente do Administrador sendo transparente para a operadora de
Telecom.
Figura 4.8 – Cenário 6 – Rede Interna IPv6 e operadora IPv4
4.1.8 - Cenário 7
O administrador utiliza somente IPv6 em sua rede e a operadora fornece
IPv6 e IPv4 em dual-stack.
Neste cenário, a operadora fornecerá para o cliente somente o IPv6 e
deverá configurar, na interface externa do CPE, um tradutor (6to4) para
acessos às redes IPv4 externas ao backbone. O administrador migrará sua
rede para IPv6 puro. A operadora terá, também, a responsabilidade de fazer a

96. 79
tradução (6to4), caso o cliente esteja tentando acessar algum site que seja
IPv4 puro e seja externo ao backbone da operadora. Um Broker deverá
funcionar dentro da operadora de Telecom.
Figura 4.9– Cenário 7 – Rede Interna IPv6 e operadora IPv4 e IPv6 (dual-stack)
4.1.9 - Cenário 8
O administrador utiliza somente IPv6 em sua rede e a operadora fornece
somente IPv6.
Neste cenário, tanto o administrador quanto a operadora utilizam IPv6
em suas redes. A responsabilidade de migração, neste caso, é igualmente
dividida entre as duas partes. A operadora terá a responsabilidade de fazer a
tradução (6to4), caso o cliente necessite acessar algum site/serviço que seja
IPv4 puro e seja externo ao backbone da operadora. Um Broker deverá
funcionar dentro da operadora de Telecom. Este, no entanto, é também um
cenário futurista, em que o backbone da operadora opera apenas com IPv6
puro.
Figura 4.10 – Cenário 8 – Rede Interna e operadora IPv6

97. 80
4.2 Configurações Realizadas
Foram efetuadas configurações nos equipamentos do laboratório,
considerando o layout físico apresentado na topologia da figura 4.1 e os
layouts lógicos apresentados, referentes aos possíveis cenários descritos
acima.
Para que todos estes cenários fossem devidamente testados, as
configurações feitas tiveram o intuito de facilitar a diferenciação de um cenário
para outro, para isso bastando apenas retirar ou inserir alguns dos
equipamentos, de forma a simular os diferentes aspectos de cada cenário.
No laboratório, o servidor DNS, DHCPv4, DHCPv6, cliente Broker,
Firewall (IPv4 e IPv6) e Gateway NAT estão agrupados na mesma máquina,
que chamamos de Roteador de Borda.
Neste capítulo, será detalhada somente a configuração desta máquina,
por ser o equipamento de maior importância e relevância nos testes de
migração realizados nos laboratórios.
Para a rede interna, chamada de LAN do laboratório, a técnica adotada
de interação entre as duas versões de IP foi o do dual-stack (configurado
somente nos equipamentos que a suportam). Para a saída WAN, interface
externa do roteador de borda, foi adotada a saída pública IPv4 com apenas um
endereço IP e o Broker IPv6 com um “prefixo” /48. A técnica utilizada na parte
WAN, apesar de se utilizar o Broker, pode ser considerada também como de
dual-stack, pois, apesar de se utilizar um túnel para alcançar a Internet IPv6,
para o roteador de borda é como se ele possuísse também as duas versões de
IP em sua pilha.
4.2.1 Roteador de Borda
4.2.1.1 Sistema Operacional utilizado e sua distribuição
O roteador de borda foi configurado em uma máquina com sistema
operacional LINUX da distribuição Gentoo (www.gentoo.org ). O Gentoo é uma

98. 81
distribuição Linux muito utilizada para servidores dedicados, por ser uma
distribuição completamente moldada ao hardware utilizado. Todo o sistema
operacional e programas podem ser instalados a partir dos fontes e as opções
referentes aos mesmos podem ser habilitadas ou não a critério da necessidade
do administrador do sistema. O Gentoo utiliza um sistema de árvore, atualizado
online, conhecido como Portage, com a finalidade de buscar o código-fonte dos
programas e suas dependências, habilitar ou desabilitar parâmetros e diversas
outras opções e, então, fazer a sua instalação no sistema operacional. Tudo
isso é feito de forma automática e transparente e, com isso, os programas e o
próprio sistema operacional se tornam mais “secos” e “limpos”, diminuindo a
opção de suporte às características desnecessárias e aumentando, assim, a
disponibilidade, a escalabilidade e a robustez do sistema como um todo. O
Portage possui uma classificação para determinar a estabilidade do programa
referente, conjuntamente com a arquitetura do processador do sistema. A
arquitetura utilizada no laboratório é para processadores padrão “x86”, apesar
de suportar diversos padrões de arquitetura como o “x64”, “ppc”,”hppa”, entre
outros. Os parâmetros de arquitetura observados no Portage para os
programas são o “x86” para programas estáveis, e “~x86” para programas que
ainda não foram considerados estáveis pela comunidade desenvolvedora do
GENTOO.
4.2.1.2 Configuração do Roteador de Borda
O roteador de borda deverá possuir, ao final, as configurações como
demonstrada na figura abaixo e, para tanto, as configurações do sistema
operacional, assim como dos serviços, serão mostradas neste tópico.

99. 82
Figura 4.11 – Roteador de borda
A figura acima representa o roteador de borda e suas interfaces de rede
em suas respectivas “zonas” de atuação. A interface “eth1” juntamente com a
interface virtual associada “sit1” estão na zona LAN da máquina, ou seja, são
as interfaces ligadas diretamente com a rede local do laboratório. Repare que a
interface “eth1” possui o sistema de pilha-dupla.
A interface virtual “sit1”, apesar de estar associada à “eth1”, é
considerada pelo sistema como uma interface independente. Esta interface é
criada pelo script do Broker e mais informações sobre seu funcionamento serão
dadas mais a frente.
A interface de loopback está associada à zona interna do roteador, e se
refere aos serviços internos do próprio sistema. Repare que a interface de
loopback possui, também, dual-stack.

100. 83
A interface “eth0” está associada à “zona” WAN. Esta interface está
ligada à operadora de Telecom e possui um IPv4 público. O endereço IPv6
existente na interface é somente o endereço criado pelo sistema,
automaticamente, com o endereço MAC da interface “eth0”.
Para ter as configurações e os recursos necessários para se montar o
layout lógico do roteador de borda como o da figura 4.11, primeiramente, foi
sincronizada a árvore de fontes dos programas da distribuição Gentoo.
4.2.1.2 Sincronia da árvore do Portage
# emerge –sync
A sincronia da árvore do Portage pode ser feita diariamente, caso se
queira, pois as versões estáveis dos softwares são atualizadas
constantemente, sendo que as versões instaladas no servidor para a
implementação do laboratório têm data de 07 de agosto de 2008, e o arquivo
obtido através do comando de sincronia da árvore do Portage é “portage-
20089807.tar.bz2”. Ocorre, então, que os programas utilizados na montagem
do roteador de borda no laboratório foram configurados com as suas versões
como as colocadas nos itens de configuração a seguir. Deve ser observado,
também, que os arquivos de configurações são relacionados as suas
respectivas versões, e os arquivos de configuração podem sofrer alterações no
decorrer da mudança das versões.
Outro fato a ser observado é referente à estabilidade da versão
disponível no Portage. As versões instaladas no laboratório são as versões
mais recentes e consideradas estáveis dos aplicativos. Obviamente, existem
versões mais recentes no Portage, porém não são consideradas estáveis e
podem existir softwares, como o DHCPv6, que não possuem versões
consideradas estáveis e, neste caso, foram instaladas as versões mais atuais
disponíveis.
Finalizada a sincronia da árvore, alguns serviços (softwares) foram
instalados com o seguinte comando:

101. 84
# USE=”IPv6” emerge vanilla-sources udhcp radvd bind dhcpv6 freenet6
shorewall iptables
Note que, no comando acima o parâmetro “USE=”IPv6”” serve para
adicionar suporte ao IPv6, caso existente, na compilação dos fontes dos
programas a serem instalados. A partir de então, os softwares instalados, que
possuírem suporte à IPv6, estarão com o mesmo habilitado. Os programas
instalados com o comando acima serão descritos a seguir, junto com o seu
versionamento, utilidade e configurações:
4.2.1.3 Programas Instalados
4.2.1.3.1 Kernel
sys-kernel/vanilla-sources-2.6.20 - Versão 2.6.20 x86
O kernel “vanilla” é o kernel puro, como o encontrado no site de
desenvolvimento do kernel (www.kernel.org), sem qualquer patch ou
modificações, muito comuns nos kernel das distribuiçoes Linux. A forma de se
compilar um kernel não será tratado por não fazer parte do escopo deste
trabalho. As telas com as opções mostrando os parâmetros que foram
atribuídos na compilação do kernel para a utilização da máquina como gateway
de borda do laboratório estão no apêndice A.1. Note que, apesar da opção
“IPv6” fornecida no comando de instalação, habilitar suporte ao IPv6, no caso
do kernel, esse suporte deve ser atribuído e compilado manualmente.
4.2.1.3.2 DHCPv4
net-misc/udhcp-0.9.8-r3 x86
O UDHCP é um servidor simples de DHCPv4, em sua implementação.
Basta somente indicar a interface de rede no qual o serviço DHCP vai ficar
“ouvindo” as requisições e o pool de endereços que serão disponibilizados para
os clientes DHCP.
No laboratório foi utilizado o pool 192.168.0.20-254/24, o servidor DNS
foi configurado como 192.168.0.1 (o próprio firewall), e o gateway padrão foi

102. 85
configurado como 192.168.0.1. A figura abaixo mostra as partes do arquivo de
configuração “udhcp.conf” que contêm essas configurações.
Configuração dos endereços do
pool IPv4, indicação da interface
que “ouvirá” o DHCP.e as
configurações opcionais como
mascara de sub-rede, default
gateway e DNS.
Figura 4.12 – Configuração UDHCP
A tela referente ao arquivo completo dos parâmetros utilizados está
disponível no apêndice A.5.
4.2.1.3.3 Router Advertisement Daemon
net-misc/ radvd-1.1 x86
O RADVd é o daemon responsável pelo serviço de RA emitido pelo
roteador de borda para os clientes IPv6 da rede interna. Não é necessária sua
configuração direta, já que todos os parâmetros colocados no arquivo “gw6c-
rtadvd.conf”, que substitui o arquivo padrão de configuração do RADVd, o
“radvd.conf”, são criados, e suas configurações são inseridas,
automaticamente, pelo programa do túnel Broker, o Freenet6, como mostrado
na figura 4.13.
Figura 4.13 – Configuração Gateway6

103. 86
Note que o prefixo “2001:05c0:1105:0900::/64” foi inserido pelo cliente
do túnel Broker ao arquivo de configuração, de forma que o RA enviado aos
clientes IPv6 da rede sempre possuam o prefixo fornecido pelo Broker. Apesar
da configuração do arquivo do RADVd ser feita pelo cliente do Broker, a
responsabilidade do envio do prefixo correspondente, além dos parâmetros de
configuração automática de IP (Stateless ou Statefull) é de responsabilidade do
RADVd. Para que os clientes IPv6 da rede buscassem algumas configurações
do DHCPv6 (no caso, a única configuração imprescindível é o endereço do
Servidor DNS), foram feitas configurações no cliente do Túnel Broker e que
serão descritas no tópico a seguir. Sua inicialização é feita, automaticamente,
pelo “script” linux.sh executado pelo cliente Freenet6.
4.2.1.3.4 Túnel Broker (freenet6)
net-misc/ freenet6-5.1 x86
O Freenet6 é um cliente para o Tunnel Broker da organização Go6
chamado Freenet6 (http://go6.net/4105/freenet.asp ). O Freenet6 é um Broker
para a Internet IPv6, utilizando a tecnologia de tunelamento descrita no capítulo
anterior.
Diferentemente da maioria dos túneis Broker’s gratuitos disponíveis, o
Freenet6 utiliza um modelo cliente/servidor para a autenticação e manutenção
do túnel, ao invés de páginas WEB de autenticação. Uma conta (usuário e
senha) é necessária ser criada no site do Broker de forma gratuita, e os
parâmetros passados pelo site devem ser colocados no cliente Freenet6,
instalados no Roteador de borda da rede.
A instalação do programa Freenet6 fornece dois arquivos importantes
para a configuração do cliente do túnel e, por conseqüência, do RADVd. Os
arquivos são:
Gw6c.conf – arquivo no qual as configurações do comportamento e
parâmetros de funcionamento do cliente do túnel Broker são configuradas,
como, por exemplo, a “verbosidade” do arquivo de log e sua localização, o

104. 87
usuário e senha da conta com o Broker, a configuração do “keepalive” da
conexão, e diversos outros parâmetros.
Linux.sh – o arquivo “linux.sh” é encontrado na pasta “/etc/freenet6/templates/”
e se refere aos parâmetros do RADVd e de sua inicialização efetuado pelo
cliente Freenet6, após a sua autenticação e o fechamento do túnel com o
Broker. Este arquivo é de suma importância apesar de não se falar muito a
respeito do mesmo nos sites de referência, devendo-se adicionar uma linha ao
arquivo, para que o RA emitido pelo Roteador de borda possua a flag do
DHCPv6 habilitada, permitindo, assim, que os clientes IPv6 da rede interna
procurem mais configurações de rede (no caso, o endereço do servidor DNS)
junto ao DHCPv6.
Figura 4.14 – Configuração RADVd
Com a inserção da opção “AdvOtherConfigFlag”, acima mostrada, os
pacotes RA emitidos pelo RADVd passaram a ter a flag de configuração pelo
DHCPv6, como mostrado nas figuras abaixo, referentes à captura dos pacotes
RA pelo sniffer .

105. 88
Figura 4.15 – Indicação do pacote RA – desabilitado
A figura acima mostra a flag desabilitada e, abaixo, a diferença quando
se é adicionada a linha de configuração para a habilitação da flag:
Figura 4.16 – Indicação do pacote RA – habilitado
O serviço de túnel então é inicializado através do comando:
# /./etc/ini.d/gw6c start
Na tela de Log do RADVd (figura 4.17) é mostrada a inicialização do
túnel, assim como a criação das rotas, utilizando-se o prefixo obtido pelo

106. 89
Broker:
Figura 4.17 – Inicialização do túnel Broker
Uma observação importante sobre a figura acima é a habilitação do
roteamento no IPv6. Este roteamento é totalmente independente do IPv4 que,
no caso, já estava previamente habilitado, caracterizando a independência das
duas pilhas, ou seja, as regras e procedimentos criados para o IPv4 são
completamente separados das regras e procedimentos para o IPv6.
Efetuada, então, a inicialização do túnel, a tabela de endereçamento IP
dada pelo comando “ifconfig” será mostrada a seguir, porém ela estará
dividida de forma a um melhor entendimento e explanação:
Figura 4.18 – Configuração da interface Eth0 – rede WAN
Executado o comando “ifconfig”, a primeira interface mostrada é a
“eth0”. Como visto no layout do Firewall, é a interface de rede WAN e a que
recebe um endereço IPv4 público da operadora. Como o kernel compilado
possui suporte à IPv6, a interface é também inicializada com um IPv6 montado
pelo próprio sistema, através do prefixo escopo link local (que não é roteável)
“FE80::2”, e, no resto, do endereço MAC da interface de rede. Note que, depois

107. 90
de um endereço IPv6, vem sempre uma referência ao escopo a que ele
pertence que, no caso acima, é “Link”, ou seja, é um endereço de rede local.
A figura 4.19 mostra a parte da interface “eth1”. Essa é a interface
interna (LAN) do firewall, e é nessa interface que o túnel junto ao Broker é
associado. É nessa interface, também, que o RADVd (gerador de RA’s ) emite
os pacotes referentes ao endereço IPv6 recebido pelo Broker. O primeiro
endereço que aparece na interface “eth1” é o IPv4 192.168.0.1/24. Esse
endereço faz parte da pilha dupla IPv4/IPv6 dessa máquina. O segundo
endereço é um IPv6. Esse é o endereço recebido pelo Broker e totalmente
construído pelo mesmo (não tem nenhuma parte do endereço MAC da
interface). Os próximos 3 endereços que aparecem na figura são endereços
IPv6, inseridos de forma manual para a interface. Esses endereços são
necessários para o Windows XP, que não possui suporte ao DHCPv6, e
assume, automaticamente, esses endereços como sendo o do DNS da rede. O
ultimo endereço é o “link local”, montado com o prefixo “fe80::2” e o MAC da
interface de rede.
Figura 4.19 – Configuração da interface eth1
A figura abaixo referencia a interface virtual SIT1. Essa interface virtual é
criada no sistema operacional pelo script linux.sh e é associada, virtualmente,
à interface física eth1. Na linha destinada ao tipo de encapsulamento, a tela
mostra “IPv6-in-IPv4” que, neste caso, é exatamente o encapsulamento no
protocolo 41 para o tunelamento utilizado pelo Broker. Essa interface recebe
um IPv6 de Escopo Global com máscara 128, ou seja, este IP é recebido pela
interface do Broker, e não faz qualquer modificação no mesmo. Este IP serve
somente para indicar o ponto-a-ponto do túnel IPv6.

108. 91
Figura 4.20 – Configuração da interface SIT1
A figura a seguir mostra a última interface, que é a de loopback. A única
observação é a existência do endereço de loopback, tanto em IPv4 como em
IPv6 (condizente com a usada no dual-stack).
Figura 4.21 – Configuração da interface Loopback
Para testar o funcionamento do túnel foi utilizado o comando Ping6
(versão IPv6 do comando ping) e foi tentado mandar pacotes ICMPv6 para o
site (www.kame.net ), que é um site conhecidamente IPv6:
Figura 4.22 – Teste de ping versão 6
Repare na figura que o endereço (www.kame.net ) é resolvido em IPv6,
mesmo este site tendo um endereço correspondente em IPv4. Outro ponto a se
observar é o tempo de latência de resposta do pacote ICMPv6 que, no exemplo
acima, é consideravelmente alto. Esses valores são obtidos devido ao uso do
Broker para atingir a internet IPv6 e, sendo assim, o pacote “viaja” por diversas
redes até chegar ao seu destino. Possivelmente, se a operadora em questão
possuísse seu próprio “Broker”, os valores de desempenho do tráfego seriam

109. 92
bem melhores. Como não se dispõe de um provedor com um Broker, não é
possível realizar sua comparação.
Figura 4.23 – Tabela de roteamento do servidor – IPv4
Verificou-se, então, que o comando route mostra, exclusivamente, a
saída somente da tabela de roteamento da pilha IPv4, pois não faz referência
alguma à interface SIT1, além dos endereços e rotas IPv6. Para tanto, o
comando que deve ser executado para se ver todas as rotas do sistema, ao
invés do “route”, sendo elas IPv4 ou IPv6, é o “routel””.
As partes de interesse estão destacadas abaixo e a saída do comando,
na íntegra, está no apêndice A.3:
A figura, a seguir, mostra a rota default para a internet IPv4 (exatamente
como a saída o comando route (figura 4.23), no campo destacado como “1”:
Figura 4.24 – Roteamento default Eth0
Porém, em continuação, na saída do comando routel, são obtidas,
também, as seguintes informações:
Figura 4.25 – Roteamento – comando routel

110. 93
a) O endereço IPv6 associado à interface Sit1 e à interface eth1 no campo
“1”.
b) A adição da rota de saída padrão para a rede IPv6 pela interface sit1
como mostrada nos campos “2” e “3”.
4.2.1.3.5 DNS (BIND9)
net-dns/bind-9.4.3_p2 x86
O Berkeley Internet Name Domain - Name Server (BIND) desenvolvido e
mantido pela Internet Systems Consortium (ISC) é o servidor DNS
disponibilizado, gratuitamente, bastante utilizado na Internet, por sua
estabilidade e robustez. O serviço de DNS é de suma importância para a
migração e funcionamento da rede IPv6, uma vez que os endereçamentos se
tornarão praticamente inviáveis de serem administrados, em sua forma
numérica, no modelo IPv6. O BIND, para funcionar com o IPv6, deve ser
compilado com suporte a “IPv6”.
Devem ser configuradas, separadamente, as zonas IPv6 e IPv4 para a
utilização pelo DNS, assim como os arquivos de resolução reversa. Os
parâmetros de cada arquivo, assim como suas respectivas telas estão no
apêndice A.2. Depois de configurado, basta inicializar o serviço de DNS com o
comando:
# /./etc/ini.d/named start
As sinalizações na tela a seguir mostram, no arquivo de log do “named”,
que o servidor DNS está “ouvindo” requisições DNS nas interfaces IPv6, porém
não faz distinção de qual interface IPv6, como é mostrado para os endereços
IPv4:

111. 94
Figura 4.26 – Arquivo de log do named
4.2.1.3.6 DHCPv6
net-misc/dhcpv6-1.0.20 ~x86
O DHCPv6 é um servidor DHCP para IPv6, porém nenhuma versão dele
disponível no momento da instalação era considerada estável pelo Portage, ou
seja, todos os pacotes dos fontes estavam marcados com a flag “~x86”.
As configurações feitas no DHCPv6 são mínimas e, apesar de ser
colocada referência do pool de endereços e do prefixo (fornecido pelo Broker),
no laboratório, não gerencia os endereços dos hosts (configuração adotada),
cabendo somente enviar para os clientes que o requisitarem (que tiverem
suporte ao DHCPv6 / IPv6 Ready Fase 2), o endereço do DNS. Repare que,
mesmo assim, foi necessário configurar um pool de endereços para o
funcionamento do serviço, pois, sem essa configuração, o servidor não aceita
ser inicializado.
A figura 4.27 mostra os campos configurados no arquivo dhcp6s.conf
(arquivo referente ao servidor DHCPv6):

112. 95
Figura 4.27 – Campos configurados no dhcp6s
4.2.1.3.7 Shorewall
net-firewall/ shorewall-3.4.8 x86
O shorewall é uma suíte de scripts, desenvolvido pela comunidade
shorewall.net para facilitar a criação e administração de regras do firewall
(iptables) do Linux. O shorewall não deve ser confundido com um firewall, pois
na verdade ele é somente um “front-end” de configuração do firewall do Linux
(IPtables).
O shorewall possui uma versão para IPv6, pois como descrito
anteriormente, quando se utiliza dual-stack, são necessárias regras específicas
para IPv4 e para IPv6 separadamente. Porém, essa versão para IPv6 não será
utilizada, pois não pretende entrar em detalhes de criação de regras de firewall
por serem “específicas” para cada situação nas diversas redes e possibilidades
existentes. Há dois motivos principais para a utilização do shorewall (versão
IPv4): o primeiro refere-se à facilidade da criação das regras de NAT; o
segundo é referente à questão da independência das pilhas, ou seja, a criação
de regras para a pilha IPv4 não pode afetar a pilha IPv6. Como o shorewall por
padrão bloqueia tudo que esteja fora das regras e interfaces declaradas, por
mais que a regra geral seja “permitir tudo” (tudo que foi previamente
declarado). A interface SIT1 (Broker IPv6) não está sendo declarada em
nenhuma parte e, se as regras da pilha IPv4 interferissem no IPv6, o tráfego

113. 96
desta interface seria totalmente bloqueado, simplesmente pela falta de
definições sobre a interface SIT1 (IPv6).
A suíte é composta por diversos arquivos, cada um com uma utilidade
específica de firewall (Ex. rules, policy, NAT,...), mas para o laboratório
somente os arquivos primários para o funcionamento do firewall foram
devidamente configurados. Os arquivos abaixo são encontrados na pasta
“/etc/shorewall/” no diretório raiz.
Figura 4.28 – Diretório do shorewall
4.2.1.3.7.1 Arquivo Interfaces
Este arquivo refere-se à associação das zonas com as interfaces de
rede que serão regidas pelo firewall, ou seja, somente as interfaces colocadas
explicitamente neste arquivo sofrerão as interações e regras criadas no firewall.
O restante da pilha IPv4 (outras interfaces IPv4) que não estiver declarada
aqui, terá bloqueada seu respectivo tráfego.
Figura 4.29 – Associação de zonas
4.2.1.3.7.2 Arquivo policy
Este aquivo define as políticas (regras) gerais associadas a cada zona,
ou seja, simplesmente definem-se as regras padrão de interação entre as
zonas. Estas regras podem ser ACCEPT (aceitar), REJECT (rejeitar), DROP
(descartar silenciosamente), entre outras, além de fazer referências ao sentido
das interações das zonas como, por exemplo, FW –> LAN (tráfego entre a o
Firewall e a LAN), LAN -> NET (Tráfego entre a LAN e a Internet IPv4) ou NET-

114. 97
>LAN (Tráfego entre a Internet IPv4 e a LAN). No experimento, configurou-se a
regra aceitar todo tipo de tráfego IPv4, não importando a zona ou o sentido.
Figura 4.30 – Configuração de tráfegos
4.2.1.3.7.3 Arquivo masq
O arquivo masq é configurado no roteador de borda somente para
habilitar o mascaramento (NAT no Linux) na interface de saída para internet
eth0.
Pode também ser utilizado para criar mascaramento entre outras
interfaces IPv4, porém este processo não será abordado neste trabalho.
Figura 4.31 – Habilita o mascaramento (NAT)
4.2.1.3.7.4 Arquivo zones
A finalidade deste arquivo é criar as zonas e configurar o tipo das
mesmas. Como no exemplo (figura 4.32), a versão do IP (IPv4) ou a máquina
firewall (interface loopback). Estas zonas são as utilizadas no arquivo
inferfaces.
Figura 4.32 – Tipo de zonas

115. 98
4.2.1.3.7.5 Arquivo shorewall.conf
Este arquivo refere-se ao serviço de firewall como um todo. É nele que
se colocam as configurações de detalhamento do arquivo de “log” ou, até
mesmo, se ele será gravado em separado ou será utilizado o arquivo de “log”
padrão do serviço de LOG do sistema operacional (“syslog”). A única opção
que merece destaque está apresentada na figura abaixo. É onde se habilita o
funcionamento firewall e, como padrão de instalação, ela vem configurada
como “No” é necessário alterar para “Yes”. Configurações Apêndice A.4
Para simplificar, as configurações efetuadas acima servem para habilitar
o roteamento IPv4, o mascaramento (NAT IPv4) e criar uma política geral de
“aceitar tudo” (que estiver declarado) para os clientes da rede interna e, assim
permitir com que eles tenham acesso à internet IPv4 através de um único IP
público e provar a independências das pilhas IPv4 e IPv6
4.2.1.3.7.6 Firewall (IPtables)
net-firewall/ iptables-1.4.0-r1 x86
IPtables é o firewall, um software desenvolvido pela comunidade
Netfilter.org para criar, alterar e gerenciar as regras e formas de lidar com
pacotes IP entrante e sainte das interfaces de rede de um host com o Linux
instalado. O IPtables é um software completo de firewall, com imensos
recursos, dos mais básicos, como filtragem simples de pacote, ou avançados
como filtros de camada 7 (filtro de aplicação) ou, até mesmo, inserir, alterar e
retirar campos específicos em pacotes de rede. O IPtables foi compilado com a
opção “IPv6”; assim o suporte existente nele ao IPv6 será habilitado.
A configuração do IPtables, neste estudo de caso, é efetuado através do
shorewall para a pilha IPv4 e através do cliente do Broker para a pilha IPv6;
sendo assim, nenhuma configuração foi feita diretamente por linhas de
comando do IPtables pelo administrador.
As configurações propostas neste capítulo foram referentes ao roteador de
borda instalado no laboratório e utilização dos testes que serão apresentados
no próximo capítulo.

116. 99
5. TESTES E ANÁLISE DE RESULTADOS
O foco na realização dos testes foi concentrado no desempenho do tráfego
de dados IPv6 em relação ao IPv4 e também foram realizados testes com os
mecanismos de tunelamentos conhecidos, túnel Broker, 6to4 e Teredo. Os
teste realizados foram abordados em duas frentes: uma foi a diferença de
velocidade (desempenho) na transmissão de dados em uma rede local, para
ser avaliada a diferença de transmissão dos pacotes IPv6 ao IPv4; o outro tipo
de teste foi em relação ao roteamento, analisando assim a diferença de
velocidade do processamento e encaminhamento do IPv6 (tunelado) ao IPv4.
5.1 Teste Rede Local ( Sem utilização de Túnel)
Por não depender de meios externos (links, provedores), o primeiro teste
realizado, foi a transferência de arquivos em uma rede local (LAN), por portas
ethernet 100baseT. Este teste foi baseado na quantidade de tráfego
transmitido, tendo em vista que o tempo de resposta é pequeno, considerando
que as duas máquinas estão no mesmo segmento de rede.
Internet IPv4
Trafego IPv6 ou IPv4
ETH0
NAT Gateway IPv4: 201.45.120.69
ETH1
IPv4: 192.168.0.1/24
IPv6 (Link-Local):fe80::250:4ff:fe9f:3ba8
IPv6 (Global): 2001:5c0:1105:900::1
LAN DualStack
IPv4/IPv6
100baseTX
IPv4: 192.168.0.102/24
IPv6 (Link-Local): fe80::240:45ff:fe27:f5b1
IPv6 (Global): 2001:5c0:1105:900:240:45ff:fe27:f5b1
Tráfego em IPv6 (Link Local) ou IPv4
IPv4: 192.168.0.101/24
IPv6 (Link-Local): fe80::221:70ff:fe99:8f41
IPv6 (Global): 2001:5c0:1105:900:221:70ff:fe99:8f41
Figura 5.1 – Topologia – Transferência de arquivos – Cabo

117. 100
A figura acima mostra a configuração realizada no laboratório para a
realização dos testes de desempenho na transferência de arquivos. Foram
testados os dois protocolos, IPv6 e IPv4. Inicialmente, foi realizado um teste de
transferência de arquivo dentro da rede LAN com as estações configuradas
somente com IPv4 e conectadas via cabo através do switch. Foi desabilitado
das estações o protocolo IPv6. Realizou-se a transferência de um arquivo de
113 Mbps da estação com endereço IP 192.168.0.102/24 para a estação com o
endereço IP 192.168.0.101/24, obtendo-se uma taxa de transferência média de
14 MB/s. Como pode ser observado na figura 5.1, a comunicação ocorre
através do endereçamento de escopo link-local, para tráfego interno na rede
LAN, e conforme já mencionado anteriormente, pacotes trafegados através do
endereço link-local não são roteados para fora da rede LAN. Em seguida,
foram alteradas as configurações das mesmas estações para IPv6 puro,
desabilitando o protocolo IPv4. Foi realizada a transferência do mesmo arquivo
de 113 Mbps. Neste teste, foi obtida uma taxa de transferência média de 13
MB/s. Realizando uma comparação entre os dois protocolos pode ser
considerado que foi obtida desempenho equivalente entre o IPv4 e IPv6, como
pode ser mostrada no gráfico abaixo. A pequena diferença apresentada pode
ser atribuída ao overhead (explicado mais ao final do capítulo) do pacote IPv6.
C onexão via C abo
19
17
B anda (MB P S )
15
Vis ta C a bo IP V4
13 Vis ta C a bo IP V6
11
9
7
1º 2º 3º 4º
Medições
Figura 5.2 – Transferência de arquivo – comparação IPv4 x IPv6 – Via Cabo

118. 101
O próximo teste realizado foi a transferência de arquivo em redes
Wireless, IEEE 802.11g, havendo uma pequena alteração na configuração, que
consiste em ligar o Access-Point (AP) na porta do switch, e as estações se
conectarem ao AP para a realização do teste. A estrutura do laboratório, então,
ficou com a seguinte topologia:
Figura 5.3 – Topologia – Transferência de arquivos - Wireless
Similar ao que foi testado no item anterior, primeiramente, foi iniciado o
teste de transferência de arquivo com as estações configuradas somente com
IPv4 e com o IPv6 desabilitado. Realizou-se a transferência do mesmo arquivo
de 113 Mbps da estação com endereço IP 192.168.0.102/24 para a estação
com o endereço IP 192.168.0.101/24, obtendo-se uma taxa de transferência
média de 614 KB/s. Em seguida, foi alterada a configuração das mesmas
estações para IPv6 puro, desabilitando o protocolo IPv4. Foi, então, realizada a
transferência deste mesmo arquivo e obteve-se, neste teste, uma velocidade

119. 102
de transferência média de 615 KB/s. Conforme foi observado nos testes
anteriores, o desempenho obtido em Wireless também foi equivalente entre os
dois protocolos, como pode ser observado no gráfico abaixo.
Medições
Figura 5.4 – Transferência de arquivo – comparação IPv4 x IPv6 – Wireless
5.2 Teste utilizando Mecanismos de Tunelamento
Para a realização de testes dos mecanismos de tunelamentos, será
considerado o tempo de latência, visto não ser possível controlar os fatores
externos, tais como: disponibilidade conectividade do link, troca de tráfego
entre os roteadores das diversas operadoras, servidores, etc. Assim,
utilizaremos o ping, que mede o tempo de reposta de uma requisição ICMP,
contemplando o caminho de ida e volta do pacote.
Para realização dos testes, serão utilizados os mecanismos de
tunelamentos túnel Broker, 6to4 e Teredo.
5.2.1 Túnel Broker
Para demonstrar o funcionamento do túnel Broker, foi necessário
realizar as configurações no laboratório de todos os ativos (estações cliente,
servidor com os serviços DHCP, DNS, roteador de borda), conforme descrito
no capítulo 4.

120. 103
O túnel Broker utilizado neste trabalho é o Freenet6 da HEXAGO e está
situado, fisicamente, no Canadá.
Inicialmente, foi realizado um teste de latência (através do comando
ping) no site do Freenet6 (www.freenet6.net ), já que, este site operada com
dual-stack (pilha dupla), aceitando requisições ICMPv4 e ICMPv6. Como o
destino dos pacotes, tanto IPv6 quanto IPv4, é o mesmo (TB Freenet6), é
possível realizar a comparação entre eles.
Para alcançar o servidor do Freenet6, utilizando o IPv4 ou IPv6, são
realizados 14 saltos, porém, no teste do IPv6, com o comando tracepath6
(verificar todos os hops existentes no caminho de origem ao destino) no IPv6, é
apresentado apenas um hop, que é o endereço da interface do túnel Server do
Broker, pois o pacote é transportado em túnel por uma rede IPv4 encapsulado
com o protocolo “41” e para o IPv6 todo o caminho é transparente. Para, então,
determinar o caminho e saltos percorrido pelo pacote do túnel na Internet IPv4
(do laboratório até o Broker), foi utilizado o comando tracepath que é para IPv4.
A Figura abaixo apresenta os hops utilizados para o alcance do servidor
Freenet6, onde é possível verificar o caminho percorrido pelo pacote IPv6
(encapsulado protocolo 41) na Internet IPv4.
Figura 5.5 – Hops para alcance do Freenet6
Após verificação dos hops partimos para os testes de desempenho.
A figura 5.5 apresenta um comparativo do tempo médio de um pacote
ICMP (v4 e v6), onde é possível verificar uma pequena diferença no
desempenho entre os dois protocolos. Esta diferença pode ser considerada
pelo processamento do túnel, pelo caminho utilizado entre o servidor de destino

121. 104
e o túnel Broker, porém ele não mede a diferença do processamento já que os
pacotes IPv6, por estarem encapsulados em IPv4 são considerados como IPv4
e são roteados pela Internet como IPv4 (até a ponta do Broker).
Figura 5.6 – Teste de Ping – Comparação IPv4 x IPv6 – Servidor Freenet6
O próximo teste realizado considerou um servidor que suporta os dois
protocolos (IPv4 e IPv6), localizado no Japão, o site www.kame.net. Este teste,
diferentemente do anterior, visa medir a diferença de processamento no
roteamento do IPv6 em comparação ao IPv4. Como o site (www.kame.net) se
localiza no Japão, e analisando as saídas por cabeamento submarino
observado na figura 5.6, concluiu-se que apesar do pacote passar por um túnel
do Canadá em diante, ele seria transmitido por backbone IPv6 puro (sem
encapsulamento), lado a lado com o backbone IPv4.
Como pode ser observada na figura 5.7 a latência média medida foi de
374 ms para IPv6 e 318 ms para IPv4, sendo a diferença superior ao teste
realizado no item anterior. Este aumento da latência leva em consideração, e
também o percurso feito pelo pacote, já que, apesar de a saída utilizada, tanto
pelo pacote IPv4 quanto pelo IPv6, para atingir o Japão, passar pelo mesmo
percurso (Figura 5.7), saindo por Seattle nos EUA, o pacote IPv6 sai do
tunelamento para a rede IPv6 somente no Broker origem, situado no Canadá,
e, aí então, retorna para Seattle por onde sai para o Japão gerando um
aumento no delay.

122. 105
Figura 5.7 – Mapa de interligação de redes – através do mar
Figura 5.8 – Teste de Ping – comparação IPv4 x IPv6 – Servidor Kame.net
O próximo teste realizado considerou um servidor que suporta os dois
protocolos (IPv4 e IPv6 em pilha dupla) localizado no Brasil, para, assim, poder
medir o desempenho dos dois protocolos com destino a sites e serviços
brasileiros. O site utilizado foi www.IPv6.br. Como pode ser observado na figura

123. 106
5.9, a latência medida foi de 320 ms para IPv6 e de apenas 25 ms para IPv4,
tendo uma diferença considerável comparando um protocolo ao outro, pois no
caso do IPv6 estamos utilizando um Broker no Canadá. Assim, só de latência
para utilização do Broker, são gastos quase 300 ms.
Verificou-se que a utilização de Broker IPv6 no Brasil só terá um
desempenho próximo ao do IPv4 no momento em que houver, no Brasil, um
serviço de Broker disponível, diminuindo, assim, o tempo gasto pelo pacote no
túnel. Apesar de ainda não existir nenhum servidor de túnel Broker no Brasil o
tunelamento tipo túnel Broker, comparado com os outros foi o que apresentou
maior estabilidade nos delays observados, apesar do tempo de retardo imposto
pela distância do Broker Freenet6 do laboratório de teste.
Figura 5.9 – Teste de Ping – Comparação IPv4 x IPv6 – Servidor IPv6.br
Realizou-se, também, a configuração e implementação de túneis 6to4 e
Teredo pelo sistema operacional Windows XP.
Inicialmente, a estação apresentava as configurações de túneis
desabilitadas e com endereço IPv4 público (válido na internet), sem a utilização
de NAT, já que as conexões dos túneis 6to4 só são possíveis quando as
estações estão configuradas com um endereço IPv4 válido.

124. 107
5.2.2 Túnel 6to4
A figura 5.10 mostra a configuração ethernet da máquina apenas com o
túnel Teredo habilitado; como pode se observar o endereço IP público
configurado da operadora é 201.45.120.70. Tem-se, também, a formação dos
endereços IPv6 com escopo link-local.
Figura 5.10 – Tela de configuração – túneis desabilitados
Inicialmente, iremos habilitar o túnel 6to4 e, para tanto, é acessado o
prompt de comando do Windows, ou cmd no menu iniciar. Utiliza-se, então, o
comando C:> netsh interface IPv6 6to4 set state enable, para, assim,
habilitar a interface 6to4.
A figura 5.11 apresenta uma topologia com o funcionamento do túnel
6to4. Como a interface ethernet está configurada com endereço IPv4 público,
o tunelamento Teredo não recebe endereço de escopo global. Somente à
interface virtual 6to4 é atribuído o endereço IPv6 com prefixo 2002::/10,
reservado pela IANA. Pode ser observado que, neste caso, não é utilizado
NAT, nem a rede LAN, onde a estação está conectada diretamente à Internet e
recebendo um endereço IPv4 público.

125. 108
Figura 5.11 – Topologia – Comunicação através de túnel 6to4
Como pode ser verificado na figura 5.12, o endereço IPv6 escopo
Global, atribuído pelo túnel 6to4, contempla o endereço IPv4 201.45.120.70
que, convertido para hexadecimal, torna-se c9.2d.78.46. Assim, tem-se a
completa formação do endereço IPv6 6to4:
2002:c92d:7846::c92d:7846
6to4 prefix = 2002,
IPv4 address = c92d:7846 (decimal é 201.45.120.70),
Subnet ID suprimido = ::
Bits restantes definido pelo sistema operacional: c92d:7846, sendo que não foi
utilizado o EUI-64 (construído com o MAC da interface).
Apesar de não utilizar o endereço EUI-64 para designar o host, o 6to4
funciona perfeitamente, porque o importante no endereço IPv6 6to4 é o IPv4
transformado em hexadecimal para que, assim, o relay 6to4 possa descobrir a
rota e o endereço IPv4 (endereço do cliente 6to4) para qual vai se mandar os
pacotes IPv6 encapsulados (protocolo 41).

126. 109
Figura 5.12 – Tela de configuração – Túnel 6to4 habilitado
Após habilitado o túnel 6to4, realizou-se um teste de ping em um site
puramente IPv6 (IPv6.google.com), de endereço 2001:4860:0:2001::68. O
tempo médio de resposta obtido, neste teste, foi de 459 ms.
Figura 5.13 – Sucesso no ping com site Google IPv6 – 6to4 IP válido
Para verificar que o túnel 6to4 não possui suporte a seu funcionamento
atrás do NAT, alterou-se o layout da conexão (figura 5.11), inserindo
novamente o computador de teste atrás do firewall (NAT IPv4), de forma à
funcionar através do NAT. O computador através do DHCPv4 recebe o IP
192.168.0.102, como mostrado na figura abaixo:

127. 110
Figura 5.14 – Configuração endereço IP através de NAT – 6to4
Depois de configurada a interface com endereço atribuído pelo NAT, foi
realizado um teste de ping no mesmo site IPv6 (IPv6.google.com) do teste
anterior, não sendo, neste caso, alcançado o destino pretendido. Interessante
observar que o sistema operacional, neste caso, tentou montar seu endereço
IPv6 6to4, porém, como ele é montado com seu endereço IPv4 privado
(192.168.0.0/24), e por ele não ser roteável, a comunicação com o site
IPv6.google.com fica inviável, pois o site não sabe a rota para este endereço
privado.
Figura 5.15 – Insucesso no ping com site Google IPv6 – 6to4 IP Nat
5.2.3 Túnel Teredo
O próximo teste que foi realizado trata-se da configuração e habilitação
do túnel Teredo no Windows XP. A figura 5.16 abaixo mostra o funcionamento
do túnel Teredo, que, conforme explicado no capítulo anterior, tem seu
funcionamento através de NAT.
Para realizarmos a configuração do túnel Teredo, primeiro foi
desabilitado o túnel 6to4; para este procedimento foi utilizado a seguinte linha
no prompt de comando:
C:> netsh interface IPv6 6to4 set state disable.

128. 111
A figura 5.16 representa a topologia utilizada para o funcionamento e
teste do túnel Teredo. A interface ethernet está configurada com endereço IPv4
privado e atrás de NAT, sendo que o detentor do IPv4 público é o NAT
Gateway.
Internet IPv4
NAT Gateway WAN IPv4: 187.36.74.7/19
Túnel Teredo IPv6
LAN IPv4: 192.168.0.1/24
Túnel 6to4 iniciado
internamente
(não funciona)
LAN IPv4
IPv4: 192.168.0.102/24
Teredo IPv6: 2001:0:4137:9e50:8000:783b:44db:ba66
Windows XP
Figura 5.16 – Topologia – Comunicação através de túnel Teredo
Para habilitar o túnel Teredo foi utilizado o seguinte comando no prompt:
C:> netsh interface IPv6 set Teredo client.
Nos sistemas operacionais Windows Vista e 2008, o túnel Teredo já vem
habilitado (o que é um problema para o administrador). A configuração da
interface ethernet está com endereço IPv4 192.168.0.102, fornecido pelo NAT
Gateway.
Figura 5.17 – Configuração endereço IP através de NAT – Túnel Teredo

129. 112
Como pode ser observado na figura abaixo, ao se habilitar o túnel
Teredo, o endereço IPv6 Global é atribuído com prefixo 2001:0::/32, também
reservado pela IANA, e assim tem-se a formação do endereço IPv6 Teredo:
2001:0:4137:9250:8000:783b:44db:ba66
Teredo prefix = 2002:0
Teredo Server Address: 4137:9250
Teredo Flag = 8000
Obfuscated Nat UDP = 783b
Obfuscated Nat Public = 44db:ba66
Figura 5.18 – Tela de configuração – Túnel Teredo habilitado – IP NAT
Depois de configurada a interface com endereço IPv4 atribuído pelo
NAT, túnel habilitado e com endereço global atribuído à interface Teredo, foi
realizado um teste de ping no mesmo site IPv6 (IPv6.google.com) do teste
anterior (teste do 6to4). Neste teste, o tempo de resposta foi muito superior ao
realizado no 6to4, sendo a latência média de 1278 ms. Esta diferença está
baseada no mecanismo de processamento e funcionamento do túnel Teredo,
que é mais complexo, porém funciona atrás de NAT, diferentemente do
tunelamento 6to4. A figura 5.19 mostra o teste de ping utilizando o tunelamento
Teredo:
Figura 5.19 – Sucesso no ping com site Google IPv6 – Túnel Teredo IP NAT

130. 113
Com o ambiente ainda configurado para o túnel Teredo, foi realizada a
modificação do layout para o correspondente ao utilizado pelo tunelamento
6to4, ou seja, a interface passará, então, a utilizar um endereço IPv4 público. A
finalidade desta modificação é para verificar que o tunelamento Teredo não
funciona a partir de um endereço IPv4 público, ao contrário do 6to4. Na figura
5.20, mesmo o túnel Teredo estando habilitado não foi atribuído o endereço
Global para a interface. Como não foi atribuído o endereço de escopo Global,
nem obtida uma rota padrão de saída, não houve condições de se realizar o
teste de Ping no site IPv6 (IPv6.google.com).
Figura 5.20 – Tela de configuração – Túnel Teredo habilitado – IP Público
A figura abaixo apresenta uma comparação da latência com a utilização
do túnel 6to4 e do túnel Teredo. Como pode ser observada, a latência medida
no Teredo é bem superior a do 6to4 e, ainda, são observadas maiores
oscilações, enquanto o 6to4 tende a ter uma constância. Essas variações são
referentes às características de funcionamento de cada tipo de túnel.
Figura 5.21 – Teste de Ping – comparação 6to4 x Teredo – servidor IPv6.google.com

131. 114
De posse dos resultados dos testes efetuados no laboratório e de toda
teoria aprendida na bibliografia, pode-se tirar algumas conclusões referentes à
diferença de desempenho entre o IPv4 e o IPv6.
Apesar de não apresentar sensível diferença nos testes de transferência
(velocidade de transferência) de arquivo em rede local, teoricamente tem-se
um pequeno aumento da utilização da banda, quando se faz a troca de IPv4
por IPv6. Isso se dá pelo overhead do pacote IPv6 que, apesar de ter o
cabeçalho fixo, é superior que a maioria dos cabeçalhos IPv4, ou seja, se os
pacotes forem pequenos, como os de VoIP ou de SNMP por exemplo, há uma
perda de desempenho, pois o throughput para o mesmo tipo de informação fica
maior em IPv6 do que no IPv4. Esse aumento do tamanho do pacote gera um
aumento de utilização da banda, pois se tem a necessidade de se passar uma
maior quantidade de bits no mesmo período de tempo. A vantagem, nesse
caso, em relação a IPv4, é que no IPv6 o tamanho máximo dos pacotes é de
até 4Gb em comparação aos 64Kb do IPv4. Dessa forma, quanto maior for a
utilização do IPv6, softwares (dentro da finalidade dele) gerando pacotes de
tamanho maior e o constante aumento da banda nos equipamentos, essa
diferença tende a diminuir.
Outro ponto a se observar é quando os pacotes passam por algum tipo
de decisão referente ao conteúdo de seus cabeçalhos, como o que ocorre no
caso do roteamento. Partindo do princípio básico da transmissão, em que os
bits dos pacotes são transmitidos de forma serial, eles chegam um a um ao
roteador, para análise de seu cabeçalho. Tem-se, então, a necessidade de
chegar todo o cabeçalho para que se tenha uma decisão em relação à rota
adotada, para se alcançar um certo destino e, assim (decidida a melhor rota), o
pacote é, então, enviado. No IPv4, já que o cabeçalho não possui tamanho fixo,
tem-se a necessidade de se fazer uma análise caso a caso dos bits recebidos
para se “separar” o cabeçalho do payload e se fazer a decisão da rota . Ao
contrário, no IPv6, bastaria os equipamentos possuírem componentes
específicos para a separação do payload e análise do cabeçalho no próprio
hardware pois, como o cabeçalho possui o tamanho fixo de 64 bytes, quando
esta quantidade determinada de bits chegar à interface, bastaria simplesmente
encaminhar este pedaço do pacote para a análise, já que se tratará

132. 115
exatamente do cabeçalho. Isso é uma vantagem em teoria, porém na prática,
os cabeçalhos IPv4, em sua grande maioria, são menores que a metade do
cabeçalho IPv6, ou seja, mesmo com essa possível “facilidade” do tratamento
do cabeçalho que o IPv6 possui, a quantidade de bits que o roteador precisa
receber para tomar a decisão (tamanho do cabeçalho) é, geralmente, maior no
IPv6 que no IPv4, e isso consome tempo, não de processamento, mas de
espera da chegada dos bits. Nos primórdios da Internet a transmissão era
muito afetada pela falta de segurança nos meios de transmissão. Muitos bits
chegavam errados e, para se ter uma informação correta, o “checksum” era
utilizado para verificar falhas na transmissão e descartar o pacote, caso não
passasse no teste de validação. Hoje, os meios de transmissão são mais
rápidos, confiáveis e com menores taxas de erros. O controle de erro se dá, na
maioria dos equipamentos, já em camada 2, ou então pelos próprios
aplicativos, retirando essa necessidade de se ter este tipo de controle também
na camada IP (camada 3). Porém, apesar dessa necessidade desse tipo
processamento (checksum) dos pacotes IPv4, hoje todo o hardware
desenvolvido já é dedicado ao processamento e encaminhamento dos pacotes
IPv4, chegando à velocidade conhecida também como “wire-rate” ou
“velocidade do cabo”, que seria a velocidade máxima de transmissão obtida
quando se retira o processamento no encaminhamento (processamento feito
por ativos). Nesse quesito, em comparação com o IPv4, o IPv6 ainda está
distante de ter equipamentos desenvolvidos para se explorar o desempenho e
recursos que o IPv6 pode proporcionar, sejam pacotes com o cabeçalho de
tamanho fixo, sejam pacotes com o ainda não utilizado campo “flow-label”.
De acordo com os dados obtidos nos testes realizados no laboratório,
pode se verificar o funcionamento dos mecanismos de tunelamento e
interoperabilidade. Utilizando-se desses dados, e da teoria adquirida, o próximo
capítulo apresenta uma compilação de práticas, embasando o administrador
em uma migração estável e segura.

133. 116
6. MELHORES PRÁTICAS PARA MIGRAÇÃO
Para este capítulo de melhores práticas, é apresentada uma lista de
verificação, com tarefas (passos) importantes para uma migração segura e
estável, de acordo com os assuntos que foram abordados neste trabalho. A
lista de verificação possuirá itens que serão explicados neste capítulo, sendo
que esses itens podem possuir algum tipo de dependência de outros itens para
que eles sejam executados. Essas dependências serão apresentadas na lista
de verificação, pois as ordens de execução dessas tarefas que possuem
dependências farão diferença, principalmente na segurança da migração.
Abaixo está o layout que foi utilizado para a montagem da lista de verificação,
considerando as 3 zonas lógicas:
a) LAN – Rede local, com todos os hosts existentes (exceto o firewall);
b) Firewall – Composto da máquina física e suas interfaces de rede;
c) WAN – Rede externa, podendo ser considerado aqui a Internet e
Provedores.
E também suas interações incluindo o sentido:
1) Tráfego originado na WAN com destino a LAN;
2) Tráfego originado na LAN com destino a WAN;
3) Tráfego originado no firewall com destino a WAN;
4) Tráfego originado na WAN com destino o firewall;
5) Tráfego originado na LAN com destino o firewall;
6) Tráfego originado no firewall com destino a LAN.

134. 117
Figura 6.1 – Layout – Distribuição Zonas Lógicas
A lista de verificação será montada considerando as seguintes premissas:
a) O tipo de Túnel utilizado para a saída WAN será o de túnel Broker;
b) Caso a própria operadora forneça IPv6, a lista de verificação permanece
a mesma;
c) Internamente, o modelo de coexistência será o de dual-stack (pilha-
dupla - IPv4/IPv6);
d) Os serviços de rede aqui tratados serão somente os serviços
necessários para comunicação entre os hosts e acesso à Internet IPv6.
6.1 WAN ( Roteador de borda IPv6)
Figura 6.2 – Layout – WAN

135. 118
Nesta sessão, serão apresentadas as tarefas que o administrador deve
tomar, que afetam somente a parte de Internet IPv6 (relacionado ao roteador
de borda). Nesta parte, o administrador obterá, ao final, um IPv6 de escopo
global para utilizar como prefixo na configuração do RA. Apesar de, no
laboratório, ser utilizado o túnel Broker, caso ocorra da operadora fornecer um
IPv6 válido para o administrador, as tarefas colocadas aqui permanecem as
mesmas, com exceção da criação da conta no Broker, pois, nesse caso, não
será necessário.
6.1.1 Criar conta no túnel Broker
Criar a conta no túnel Broker é simples, bastando apenas acessar o site
do Broker escolhido, fazer o cadastro para obtenção de usuário e senha, baixar
o script de configuração, ou mesmo executar os passos apresentados no site
para uma configuração sem script. O que se torna mais “complexo”, neste
caso, é a escolha do Broker a ser utilizado. Como visto no capítulo 3 deste
trabalho, a grande diferença (inclusive um dos quesitos por que o Broker foi
escolhido como a forma de tunelamento recomendada neste trabalho) é que
ele possui uma única saída de interfaceamento entre a Internet IPv4 e a IPv6.
O endereço do túnel Server enviado para o Broker Client (mesmo que seja
mais de um endereço, ele envia somente um) não fica mudando de forma
dinâmica como ocorre nos Relays 6to4.
A escolha do Administrador, neste caso, deve sempre recair em
quantidade de banda disponível deste Broker e onde se localizam os Tunnel
Servers do mesmo (quanto mais próximo da rede melhor). Infelizmente, aqui no
Brasil ainda não não dispõe de serviço de Broker público. O utilizado neste
trabalho (Freenet6) localiza-se no Canadá.
6.1.2 Implantar roteador de borda do túnel
Nesta tarefa, o administrador deve configurar o roteador de borda da
rede para à Internet IPv6. Pode ser um roteador Appliance ou mesmo um
computador montado para essa saída. No laboratório, a máquina utilizada para
esta finalidade foi o próprio firewall da rede. A observação é que este host

136. 119
tenha a capacidade de montar o túnel com o Broker (através do protocolo 41) e
gerar os pacotes de RA para a LAN com o prefixo obtido pelo Broker, além de
poder configurar a flag necessária para a utilização de DHCPv6.
6.1.3 Configurar o serviço de RA com o prefixo recebido pelo Broker
Este item contempla somente a tarefa de configuração do serviço de RA
no roteador de borda. Este serviço é importante para os clientes da rede
montarem seus endereços IPv6 de escopo Global, e, assim, terem saída para a
Internet IPv6. Outro ponto a ser configurado no serviço de RA é a flag de
utilização de DHCPv6 para complemento de endereços como o DNSv6 ou o
NTPv6.
6.2 LAN ( Exceto firewall)
Figura 6.3 – Layout – LAN
Nesta etapa, estão englobados todos os ativos que ficam na LAN, como,
por exemplo, os computadores, impressoras de rede, switches, servidores,
entre outros, excluindo somente o firewall e sua interface LAN.
6.2.1 Geral
As tarefas desta seção servem para todos os ativos descritos acima,
incluindo os servidores, apesar dos mesmos possuírem tarefas específicas que
serão discutidas mais à frente.

137. 120
6.2.1.1 Levantar firmwares e softwares em produção mapeando os que
possuem suporte somente à IPv4
Antes de uma migração, seja ela qual for, uma parte importante para o
administrador é possuir de forma atualizada, informações (podendo ser uma
tabela, por exemplo) do hardware e software existentes em sua rede. Apesar
de não ser uma tarefa trivial, o administrador necessitará dessas informações
para prosseguir com as próximas tarefas de migração.
De posse das informações requisitadas, o Administrador deve verificar
quais, dos ativos existentes em sua rede interna, possuem somente suporte ao
IPv4 e separá-los em uma categoria a parte.
6.2.1.2 Dividir firmware e software que possuem suporte em duas fases
do IPv6 Ready (Fase 1 e Fase 2)
Dos ativos restantes à triagem efetuada no item acima, o administrador
deverá fazer uma nova triagem, mas, dessa vez, como todos possuem algum
suporte à IPv6, classificar segundo as duas fases apresentadas no capítulo 3, o
IPv6 ready (Fase 1 e Fase 2).
6.2.1.3 Atualizar os SO's e firmwares que possuírem atualização de
suporte ao IPv6
De posse dessa lista classificada, o administrador deve procurar, nos
sites dos fabricantes do software e hardware, possíveis atualizações que
sirvam para adicionar o suporte ao IPv6, ou mesmo melhorá-lo.
6.2.1.4 Habilitar a pilha-dupla (IPv6/IPv4) e DHCPv6 nos hosts
Nesta etapa, o Administrador deve habilitar a pilha IPv6 em todos os
hosts com suporte a IPv6 e, nos hosts que possuem suporte ao DHCPv6,
habilitá-lo também. Esses passos só deverão ser efetuados caso as tarefas
6.1.3, 6.2.3.2.3, 6.2.2.1.1.2, 6.2.2.1.2.3 e 6.2.3.1.1 tenham sido previamente
executadas, para que sistemas que possuam tunelamento automático não
abram brechas de segurança na rede, quando utilizando tunelamento Teredo,
ou até mesmo um cliente de Broker em uma máquina interna. Uma observação
importante é verificar quais são os endereços IPv6 de DNS que os hosts, que

138. 121
não possuam suporte ao DHCPv6, colocam automaticamente em sua tabela
rede (O Windows XP coloca “fec0:0:0:ffff:1” a “fec0:0:0:ffff:3” como endereço
dos servidores DNS). Esses endereços serão utilizados na configuração do
servidor DNS mais a adiante.
Outra observação desta tarefa está relacionada ao tempo e à estratégia
adotada para sua execução. Como o dual-stack foi desenvolvido para a
coexistência das duas versões, sua habilitação não prejudica as
funcionalidades da pilha IPv4 em funcionamento.
6.2.1.5 Verificar atualizações de versionamento e segurança referente
ao IPv6
Esta tarefa está relacionada à manutenção dos sistemas e SO’s, para
que eles sempre possuam a versão da pilha IPv6 mais recente. Ela é essencial
para a manutenção da segurança e estabilidade da migração. Infelizmente,
essa parte é completamente dependente dos fabricantes de equipamentos e
software utilizados na rede e, por isso, podem demorar a aparecer no mercado
atualizações ou, até mesmo, nunca chegarem a existir (para hardware e
software legados).
6.2.2 Específicos
Esta sessão trata de tarefas que são específicas a certos ativos
utilizados em uma rede, como exemplo de alguns servidores.
6.2.2.1 Servidores
6.2.2.1.1 DHCPv6
6.2.2.1.1.1 Implantar o serviço DHCPv6 e habilitar o IPv6 na interface
de rede
Esta tarefa corresponde à instalação do serviço de DHCPv6 e a
habilitação do protocolo IPv6 na sua interface que irá “escutar” o serviço. O
comando utilizado para instalar o servidor DHCPv6 na máquina utilizada no
laboratório está no capítulo 4 da Figura 4.27.

139. 122
6.2.2.1.1.2 Inserir o(s) endereço(s) de escopo link-local do DNS nos
pacotes do DHCPv6
Apesar dos hosts que possuem pilha-dupla serem capazes de formar
seu endereço escopo link-local e global (a partir do RA) sozinhos, as
configurações adicionais como, por exemplo, o endereço do servidor DNS
precisam ser adicionados ao DHCPv6 para que os hosts busquem essa
configuração e a adicionem em seus registros IP.
6.2.2.1.2 DNSv6
6.2.2.1.2.1 Habilitar DNS para suportar IPv6 e habilitar o IPv6 em sua
interface de rede
O servidor DNS, além de ter a pilha-dupla iniciada, precisa estar
habilitado a “escutar” as requisições quad-A (AAAA) para resolução em IPv6,
pois, caso não esteja atribuído de forma explícita, somente escutará as queries
“A” do IPv4. Para maiores detalhes, essas configurações estão mostradas no
apêndice A.2.
6.2.2.1.2.2 Configurar as zonas Internas para o IPv6
É necessário fazer uma configuração análoga à feita em relação às
zonas no IPv4. Para que os hosts que forem utilizar IPv6 acessem os serviços
da rede interna (LAN), que possuam suporte tanto a IPv4 como a IPv6, fazendo
com que um nome da rede tenha seu mapeamento tanto em IPv4 como em
IPv6, mesmo estando na mesma zona. As configurações estão no apêndice
A.2.
6.2.2.1.2.3 Habilitar endereços na interface IPv6 fec0:0:0:ffff::1 a ::3
(Site-Local) para uso de equipamentos IPv6 Ready Fase 1
Esta tarefa é uma parte da migração necessária para alguns SO’s, e
equipamentos que suportam IPv6 somente Fase 1. Estes hosts não possuem
suporte ao DHCPv6 e para tanto, eles utilizam um tipo de endereçamento
chamado “Site-Local” com o prefixo “fec0::/10” mas que está desuso devido,
conforme descrito na RFC 3879.

140. 123
6.2 Firewall
Figura 6.4 – Layout – firewall
Esta sessão refere-se às tarefas específicas que serão executadas no
firewall da rede e em suas interfaces, pois seu tratamento deverá ser
diferenciado dos demais hosts, inclusive porque algumas das tarefas
executadas aqui são tarefas predecessoras às tarefas de outros servidores e
dos hosts.
6.2.1 Habilitar o IPv6 nas interfaces de rede
Os IPs formados pela autoconfiguração no momento da habilitação do
IPv6 são de escopo Link-Local (“fe80::/10”) e não são roteáveis; sendo assim, a
mera habilitação dos mesmos não habilita o roteamento em IPv6.
6.2.2 Habilitar o roteamento IPv6 e bloquear seu tráfego
O roteamento da pilha IPv6, como descrito na tarefa acima, é separado
do roteamento IPv4 pelo princípio da pilha-dupla que apesar de possuir os dois
hosts tem regras de tráfego separado para IPv4 e IPv6. Nesta tarefa, o
administrador habilitará o roteamento da pilha IPv6 e bloqueará, por padrão, o
tráfego de pacotes de 1 a 6.

141. 124
6.2.3 Criar regras no firewall
As regras de firewall serão diferenciadas em IPv4 e IPv6 por conta da
independência das pilhas. Neste item, só serão tratadas as regras de IPv4 que
possuem algum impacto na segurança ou estabilidade do IPv6.
6.2.3.1 IPv4
6.2.3.1.1 Bloquear o protocolo 41 e portas UDP 3544
Essa tarefa refere-se ao bloqueio de tráfego do protocolo IPv4 do tipo 41
nos sentidos “1” e “2”, utilizado pela comunicação através de tunelamento 6to4,
e, também, pelo túnel Broker, e de pacotes UDP na porta 3544, utilizado pelo
tunelamento Teredo. A finalidade deste bloqueio é impedir que hosts internos
(LAN) criem túneis IPv6, conseguindo transpor as regras do firewall e, assim,
abrir brechas na segurança da rede, permitindo que pacotes IPv6 de escopo
Global não sejam filtrados pelas regras IPv6 criadas no firewall.
6.2.3.2 IPv6
6.2.3.2.1 Liberar as portas dos serviços a serem utilizados (basear nos
serviços IPv4)
Nesta tarefa, o administrador deve liberar as portas referentes aos
serviços que ele vai fornecer para os usuários, tanto para os hosts internos
(LAN) como para hosts na Internet IPv6 (Ex. servidor WEB em sua DMZ). Da
mesma forma que existem regras para o tráfego IPv4. Considera-se que, no
máximo (no início de uma migração), os serviços utilizados em IPv6 sejam os
mesmos que os de IPv4 e filtra-se o resto que o administrador considerar
desnecessário.
6.2.3.2.2 Filtrar o tráfego de tipos ICMPv6 que não são essenciais
Para o ICMPv6, existem algumas diferenças em relação ao ICMPv4, por
possuir uma quantidade maior de funcionalidades a mais. Alguns pacotes,
porém, são importantes para o funcionamento do IPv6 e seus recursos; o

142. 125
administrador deve seguir a mesma política e regras utilizadas de filtragem
para os pacote ICMPv4 caso possua alguma.
Abaixo estão os pacotes ICMPv6 e uma sucinta descrição dos que são
necessários trafegar (não filtrar) para se utilizar adequadamente os recursos do
IPv6 como tráfego entre o firewall e os hosts “1”,“3”, “4”, “5” e “6”: (Figura 6.1)
a) ICMPv6 Tipo 1 Código 0 – “Não há rota para o destino”;
b) ICMPv6 Tipo 3 – “Tempo excedido”;
c) ICMPv6 Tipo 128 e Tipo 129 – “echo request” e “echo reply”;
E os tipos necessários que trafegam nos sentidos “1”, “2”, “3”, “4”, “5” e “6”:
a) ICMPv6 Tipo 2 – “Pacote muito grande”;
b) ICMP Tipo 130-132 – “Multicast Listener Messages” Necessário para o
firewall e a LAN participar do roteamento multicast;
c) ICMPv6 Tipo 133/134 – Pacotes RA e RS;
d) ICMPv6 Tipo 135/136 – “Neighbor Solicitation” e “Neighbor
Advertisement” - pacotes requeridos para a detecção de endereços
duplicados (faz o papel do ARP no IPv4);
e) ICMPv6 Tipo 4 – “Problema em um parâmetro no pacote”; necessário
para caso algum host não consiga identificar ou processar algum campo
no pacote IPv6.
6.2.3.2.3 Permitir o tráfego de pacote RA para LAN provenientes do
roteador de borda (Túnel IPv6), sentido “1” (Figura 6.1)
Com essa tarefa o administrador estará liberando os pacotes de RA,
provenientes do roteador de borda para alcançarem a LAN e, assim, os hosts
conseguem configurar seus IP de escopo global e, aqueles que suportam,
conseguem buscar o DHCPv6 para configurações adicionais.

143. 126
Com as informações obtidas acima, realizou-se um planejamento de
migração utilizando-se das melhores práticas, com o intuito de averiguar o
tempo necessário para sua execução.
Considerando-se uma rede gerenciada de médio porte com 100
estações, um profissional atuando como administrador da rede e dois
profissionais atuando como técnicos de suporte aos usuários e estações.
Tendo em vista que a rede em produção deve permanecer operando sem
“downtime” (nada de IPv4 será desabilitado), deve ser mantido um técnico para
as atividades de suporte aos usuários e outro exclusivo para atividades da
migração. O administrador será responsável pelas configurações dos
servidores, túneis e firewall e o técnico, para as atividades referentes às
estações. Para facilitar a execução das atividades, foi criada uma tabela
(apêndice B.1) contendo o nome das tarefas necessárias para migração, as
dependências das tarefas e uma duração estimada para sua execução, na rede
proposta acima. Foi também elaborado um fluxograma (apêndice B.2 ) para um
melhor entendimento das dependências entre as tarefas a serem executadas,
finalizando assim, o propósito do capítulo.

144. 127
7. CONCLUSÃO
O IPv6 realmente veio para substituir o atual IPv4. O IPv4 possui
características que foram implementadas em um período que não se tinha
noção de que a Internet seria o que é hoje e, por isso, sua idealização não
previu diversos tipos de recursos que hoje se fazem necessários. As
características do IPv6 são voltadas a suprir as necessidades dos novos
serviços de comunicação em tempo real, o que não ocorreu com o IPv4. Sua
implementação não é simples e deverá ocorrer de forma gradual, coexistindo
com o IPv4 durante um longo período. Curiosamente, apesar do esgotamento
do IPv4 estar relativamente próximo, o fato não chama a atenção dos usuários
em geral, nem mesmo dos administradores de rede, pois, para os mesmos, o
provimento dos serviços de internet e conectividade WAN é de inteira
responsabilidade das operadoras, pois a internet pode ser considerada similar
aos produtos de commodity, como energia elétrica, água, petróleo, não
importando para os usuários, a forma de como os serviços são
disponibilizados.
As melhores práticas propostas neste trabalho prevêem a coexistência
entre os dois protocolos, assim como a manutenção de serviços e software que
ainda dependam exclusivamente do IPv4, e, por isso, em todos os testes
realizados no laboratório foram observadas as características deste
funcionamento “duplo” da rede. Apesar do objetivo final das melhores práticas
ser a migração do IPv4 para o IPv6 puro, o planejamento deve considerar a
coexistência dual-stack enquanto perdurar na rede, hosts, softwares, sites de
internet e serviços legados, que suportem apenas IPv4. Deve ser observada
também, a dependência entre determinadas tarefas, pois o não cumprimento
pode acarretar falhas de segurança no processo de migração, colocando a
rede local em risco.
Foi constatado que o tráfego interno (LAN) não demonstrou piora em seu
desempenho, comparado com o tráfego externo (WAN), que, por utilizar-se de
mecanismo de tunelamento (protocolo 41), provoca um aumento do delay,

145. 128
prejudicando assim, a comunicação aos hosts IPv6 na Internet. Um dos fatores
predominantes para este aumento refere-se à inexistência de servidores de
Brokers, 6to4 e Teredo no backbone da Internet brasileira, levando assim à
necessidade de utilização de servidores externos ao Brasil para a inclusão na
Internet IPv6. Como solução para o problema encontrado, seria necessário que
os detentores do backbone IPv6 no Brasil, por exemplo, CGI e RNP,
implantassem serviços de Broker, 6to4 e Teredo, incentivando a adoção da
tecnologia IPv6.
Outra forma de incentivo à adoção ao IPv6 seria as operadoras de telecom,
em conjunto com os grandes portais de serviços da internet, fomentarem
políticas de benefícios, como, por exemplo, a operadora priorizar o tráfego IPv6
em seu backbone, e também os grandes portais (bancos, agências de notícias,
sites de buscas, etc) priorizarem os serviços IPv6.
Para trabalhos futuros relacionados ao tema, sugere-se os seguintes:
1) Analisar o desempenho do uso de QoS em videoconferência nas redes
puramente IPv6.
2) A criação de um servidor de túnel brasileiro (Broker,6to4 e Teredo).
3) Análise com foco nas falhas de segurança apresentadas no IPv6,
utilizando ferramentas de ataques. THC Toolkit (alive6, parasit6, fake-
advertiser6, dos-new-ipv6,etc,) para detecção de NDP Spoofing ou
ataques Man-in-the-middle em IPv6.

146. 129
BIBLIOGRAFIA
BRADNER, Scott O., et al. RFC 1752 IPNG, Internet Protocol Next Generation,
Addison- Wesley Publishing Company, 1996.
6BONE. Testes para o desenvolvimento do IPv6. [on-line]. Disponível na
Internet via www. url: http://www.6bone.net/ Consulta realizada em 12 de
Outubro de 2008.
FREENET6 ou 6GO ou HEXAGO . Provedora de backbone IPv6 e provedora
6to4 e Túnel Broker. Disponível na Internet via www. url:
http://go6.net/4105/freenet.asp Consulta realizada em 05 de janeiro de 2009.
GENTOO.ORG. Site da distribuição LINUX GENTOO utilizada no laboratório,
contendo documentação e fóruns. Disponível na Internet via www. url:
http://www.gentoo.org/ Consulta realizada em 12 de Outubro de 2008.
IPV6.BR. Site vinculado à cgi.br (Comitê Gestor da Internet no Brasil) que
apóia o desenvolvimento de aplicações e implementação em IPv6 no Brasil.
Disponível na Internet via www. url: http://www.IPv6.br. Consulta realizada em
08 de janeiro de 2009.
IPV6FORUM. Site com fórum de discussão oficial do IPv6. Disponível na
Internet via www. url: http://www.IPv6forum.com/. Consulta realizada em 08 de
janeiro de 2009.
IPV6.COM. Site oficial do IPv6, com vasta documentação sobre o assunto.
Disponível na Internet via www. url:http://www.IPv6.com/. Consulta realizada
em 08 de janeiro de 2009.
IPV6TF.ORG. Portal do IPv6 na Internet. Disponível na Internet via www. url:
http://www.IPv6tf.org/. Consulta realizada em 08 de janeiro de 2009.

147. 130
TECHNET.MICROSOFT.COM. Microsoft TechNet é um programa da Microsoft
para adquirir informações tecnicas voltada aos profissionais de TI. Disponível
na Internet via www. url:http://technet.microsoft.com. Consulta realizada em 08
de janeiro de 2009.
HURRICANE ELECTRIC – Uma das maiores operadores gratuitas de Tunel
Broker. Disponível na Internet via www. url: http://tunnelBroker.net/
IETF - Internet Engineering Task Force. Informações oficiais relacionadas ao
Ipng. [on-line]. Disponível na Internet via www. url:
http://www.ietf.org/ids.by.wg/ipngwg.html . Consulta realizada em 15 de
Outubro de 2008.
HAGEN, Silvia. IPv6 Essentials. O'Reilly, 2002.
RNP - REDE NACIONAL DE ENSINO E PESQUISA.A Nova Geração de
Protocolos IP [on-line]. Disponível na Internet via www. url:
http://www.rnp.br/newsgen/9811/intr-IPv6.html . Consulta realizada em de
Outubro de 2008.
BRADNER, Scott O., et al. RFC 1752 IPNG, Internet Protocol Next Generation,
Addison- Wesley Publishing Company, 1996.
Cisco Systems – Cisco IPv6 Solutions -
http://www.cisco.com/en/US/technologies/tk648/tk872/tk373/technologies_white
_paper09186a00802219bc.html - Consulta realizada em Janeiro de 2009.
RFC2460: HINDEN, Robert M. e DEERING, Stephen E., Internet Protocol,
Version 6 (IPv6) Specification, 1998.
RFC1752 - The Recommendation for the IP Next Generation Protocol The
Recommendation for the IP Next Generation Protocol. S. Bradner, A. Mankin.
January 1995.

148. 131
RFC4193 Unique Local IPv6 Unicast Addresses. R. Hinden, B. Haberman.
October 2005.
RFC2461 Neighbor Discovery for IP Version 6 (IPv6). T. Narten, E. Nordmark,
W. Simpson. December 1998.
RFC2710 Multicast Listener Discovery (MLD) for IPv6 S. Deering, W. Fenner,
B. Haberman. 1999.
RFC2463 Internet Control Message Protocol (ICMPv6) for the Internet Protocol
Version 6 (IPv6) Specification. A. Conta, S. Deering, 1998.
RFC2827 Network Ingress Filtering: Defeating Denial of Service Attacks Which
Employ IP Source Address Spoofing. P. Ferguson, D. Senie, 2000.
RFC3484 Default Address Selection for IPv6. R. Draves Microsoft Research ,
2003.
RFC4477 Dynamic Host Configuration Protocol (DHCP): IPv4 and IPv6 Dual-
Stack Issues, Chown, T., Venaas, S., and C. Strauf, 2006.
RFC 2983 Differentiated Services and Tunnels. D. Black, 2000
RFC3168 The Addition of Explicit Congestion Notification (ECN) to IP. K.
Ramakrishnan, S. Floyd, D. Black, 2001.
RFC5214 Intra-Site Automatic Tunnel Addressing Protocol (ISATAP). F.
Templin,T. Gleeson,D. Thaler, 2008
RFC3056 Connection of IPv6 Domains via IPv4 Clouds. B. Carpenter, K.
Moore, 2001.
RFC4213 Basic IPv6 Transition Mechanisms, Nordmark & Gilligan Standards,
2005.

149. 132
RFC3964 Security Considerations for 6to4, Pekka Savola & Chirayu Patel,
2004.
RFC3053 IPv6 Tunnel Broker, Alain Durand, 2001.
RFC4380 Teredo: Tunneling IPv6, Christian Huitema, 2006.
RFC4213 Basic Transition Mechanisms for IPv6 Hosts and Routers, Erik
Nordmark & Robert E. Gilligan, 2005.

150. 133
APÊNDICE A
A.1 - Configuração do Kernel ( parte referente ao IPv6)
#
# Automatically generated make config: don't edit
# Linux kernel version: 2.6.26
# Wed Nov 12 13:18:35 2008
#
# Networking
#
CONFIG_NET=y
#
# Networking options
#
CONFIG_PACKET=y
CONFIG_PACKET_MMAP=y
CONFIG_UNIX=y
CONFIG_XFRM=y
CONFIG_XFRM_USER=y
CONFIG_XFRM_SUB_POLICY=y
CONFIG_XFRM_MIGRATE=y
CONFIG_XFRM_STATISTICS=y
CONFIG_NET_KEY=m
CONFIG_NET_KEY_MIGRATE=y
CONFIG_INET=y
CONFIG_IP_MULTICAST=y
CONFIG_IP_ADVANCED_ROUTER=y
CONFIG_ASK_IP_FIB_HASH=y
# CONFIG_IP_FIB_TRIE is not set
CONFIG_IP_FIB_HASH=y
CONFIG_IP_MULTIPLE_TABLES=y
CONFIG_IP_ROUTE_MULTIPATH=y
CONFIG_IP_ROUTE_VERBOSE=y
CONFIG_IP_PNP=y
CONFIG_IP_PNP_DHCP=y
CONFIG_IP_PNP_BOOTP=y
CONFIG_IP_PNP_RARP=y
CONFIG_NET_IPIP=m
CONFIG_NET_IPGRE=m
CONFIG_NET_IPGRE_BROADCAST=y
CONFIG_IP_MROUTE=y
CONFIG_IP_PIMSM_V1=y
CONFIG_IP_PIMSM_V2=y
CONFIG_ARPD=y
CONFIG_SYN_COOKIES=y
CONFIG_INET_AH=y
CONFIG_INET_ESP=y
CONFIG_INET_IPCOMP=y
CONFIG_INET_XFRM_TUNNEL=y
CONFIG_INET_TUNNEL=y
CONFIG_INET_XFRM_MODE_TRANSPORT=y
CONFIG_INET_XFRM_MODE_TUNNEL=y
CONFIG_INET_XFRM_MODE_BEET=y
CONFIG_INET_LRO=y
CONFIG_INET_DIAG=y
CONFIG_INET_TCP_DIAG=y
CONFIG_TCP_CONG_ADVANCED=y
CONFIG_TCP_CONG_BIC=m
CONFIG_TCP_CONG_CUBIC=y
CONFIG_TCP_CONG_WESTWOOD=m
CONFIG_TCP_CONG_HTCP=m

151. 134
# CONFIG_TCP_CONG_HSTCP is not set
# CONFIG_TCP_CONG_HYBLA is not set
# CONFIG_TCP_CONG_VEGAS is not set
# CONFIG_TCP_CONG_SCALABLE is not set
# CONFIG_TCP_CONG_LP is not set
# CONFIG_TCP_CONG_VENO is not set
# CONFIG_TCP_CONG_YEAH is not set
# CONFIG_TCP_CONG_ILLINOIS is not set
# CONFIG_DEFAULT_BIC is not set
CONFIG_DEFAULT_CUBIC=y
# CONFIG_DEFAULT_HTCP is not set
# CONFIG_DEFAULT_VEGAS is not set
# CONFIG_DEFAULT_WESTWOOD is not set
# CONFIG_DEFAULT_RENO is not set
CONFIG_DEFAULT_TCP_CONG="cubic"
# CONFIG_TCP_MD5SIG is not set
# CONFIG_IP_VS is not set
CONFIG_IPV6=y
CONFIG_IPV6_PRIVACY=y
CONFIG_IPV6_ROUTER_PREF=y
CONFIG_IPV6_ROUTE_INFO=y
CONFIG_IPV6_OPTIMISTIC_DAD=y
CONFIG_INET6_AH=m
CONFIG_INET6_ESP=m
CONFIG_INET6_IPCOMP=m
CONFIG_IPV6_MIP6=m
CONFIG_INET6_XFRM_TUNNEL=m
CONFIG_INET6_TUNNEL=y
CONFIG_INET6_XFRM_MODE_TRANSPORT=y
CONFIG_INET6_XFRM_MODE_TUNNEL=y
CONFIG_INET6_XFRM_MODE_BEET=y
CONFIG_INET6_XFRM_MODE_ROUTEOPTIMIZATION=y
CONFIG_IPV6_SIT=y
CONFIG_IPV6_NDISC_NODETYPE=y
CONFIG_IPV6_TUNNEL=y
CONFIG_IPV6_MULTIPLE_TABLES=y
CONFIG_IPV6_SUBTREES=y
CONFIG_IPV6_MROUTE=y
CONFIG_IPV6_PIMSM_V2=y
CONFIG_NETWORK_SECMARK=y
CONFIG_NETFILTER=y
CONFIG_NETFILTER_DEBUG=y
CONFIG_NETFILTER_ADVANCED=y
#
# Core Netfilter Configuration
#
CONFIG_NETFILTER_NETLINK=y
CONFIG_NETFILTER_NETLINK_QUEUE=y
CONFIG_NETFILTER_NETLINK_LOG=y
CONFIG_NF_CONNTRACK=y
CONFIG_NF_CT_ACCT=y
CONFIG_NF_CONNTRACK_MARK=y
CONFIG_NF_CONNTRACK_SECMARK=y
CONFIG_NF_CONNTRACK_EVENTS=y
CONFIG_NF_CT_PROTO_DCCP=y
CONFIG_NF_CT_PROTO_GRE=y
CONFIG_NF_CT_PROTO_SCTP=y
CONFIG_NF_CT_PROTO_UDPLITE=y
CONFIG_NF_CONNTRACK_AMANDA=y
CONFIG_NF_CONNTRACK_FTP=y
CONFIG_NF_CONNTRACK_H323=y
CONFIG_NF_CONNTRACK_IRC=y
CONFIG_NF_CONNTRACK_NETBIOS_NS=y
CONFIG_NF_CONNTRACK_PPTP=y
CONFIG_NF_CONNTRACK_SANE=y
CONFIG_NF_CONNTRACK_SIP=y
CONFIG_NF_CONNTRACK_TFTP=y

152. 135
CONFIG_NF_CT_NETLINK=y
CONFIG_NETFILTER_XTABLES=y
CONFIG_NETFILTER_XT_TARGET_CLASSIFY=y
CONFIG_NETFILTER_XT_TARGET_CONNMARK=y
CONFIG_NETFILTER_XT_TARGET_DSCP=y
CONFIG_NETFILTER_XT_TARGET_MARK=y
CONFIG_NETFILTER_XT_TARGET_NFQUEUE=y
CONFIG_NETFILTER_XT_TARGET_NFLOG=y
CONFIG_NETFILTER_XT_TARGET_NOTRACK=y
CONFIG_NETFILTER_XT_TARGET_RATEEST=y
CONFIG_NETFILTER_XT_TARGET_TRACE=y
CONFIG_NETFILTER_XT_TARGET_SECMARK=y
CONFIG_NETFILTER_XT_TARGET_CONNSECMARK=y
CONFIG_NETFILTER_XT_TARGET_TCPMSS=y
CONFIG_NETFILTER_XT_TARGET_TCPOPTSTRIP=y
CONFIG_NETFILTER_XT_MATCH_COMMENT=y
CONFIG_NETFILTER_XT_MATCH_CONNBYTES=y
CONFIG_NETFILTER_XT_MATCH_CONNLIMIT=y
CONFIG_NETFILTER_XT_MATCH_CONNMARK=y
CONFIG_NETFILTER_XT_MATCH_CONNTRACK=y
CONFIG_NETFILTER_XT_MATCH_DCCP=y
CONFIG_NETFILTER_XT_MATCH_DSCP=y
CONFIG_NETFILTER_XT_MATCH_ESP=y
CONFIG_NETFILTER_XT_MATCH_HELPER=y
CONFIG_NETFILTER_XT_MATCH_IPRANGE=y
CONFIG_NETFILTER_XT_MATCH_LENGTH=y
CONFIG_NETFILTER_XT_MATCH_LIMIT=y
CONFIG_NETFILTER_XT_MATCH_MAC=y
CONFIG_NETFILTER_XT_MATCH_MARK=y
CONFIG_NETFILTER_XT_MATCH_OWNER=y
CONFIG_NETFILTER_XT_MATCH_POLICY=y
CONFIG_NETFILTER_XT_MATCH_MULTIPORT=y
CONFIG_NETFILTER_XT_MATCH_PKTTYPE=y
CONFIG_NETFILTER_XT_MATCH_QUOTA=y
CONFIG_NETFILTER_XT_MATCH_RATEEST=y
CONFIG_NETFILTER_XT_MATCH_REALM=y
CONFIG_NETFILTER_XT_MATCH_SCTP=y
CONFIG_NETFILTER_XT_MATCH_STATE=y
CONFIG_NETFILTER_XT_MATCH_STATISTIC=y
CONFIG_NETFILTER_XT_MATCH_STRING=y
CONFIG_NETFILTER_XT_MATCH_TCPMSS=y
CONFIG_NETFILTER_XT_MATCH_TIME=y
CONFIG_NETFILTER_XT_MATCH_U32=y
CONFIG_NETFILTER_XT_MATCH_HASHLIMIT=y
#
# IP: Netfilter Configuration
#
CONFIG_NF_CONNTRACK_IPV4=y
CONFIG_NF_CONNTRACK_PROC_COMPAT=y
CONFIG_IP_NF_QUEUE=m
CONFIG_IP_NF_IPTABLES=y
CONFIG_IP_NF_MATCH_RECENT=y
CONFIG_IP_NF_MATCH_ECN=y
CONFIG_IP_NF_MATCH_AH=y
CONFIG_IP_NF_MATCH_TTL=y
CONFIG_IP_NF_MATCH_ADDRTYPE=y
CONFIG_IP_NF_FILTER=y
CONFIG_IP_NF_TARGET_REJECT=y
CONFIG_IP_NF_TARGET_LOG=y
CONFIG_IP_NF_TARGET_ULOG=y
CONFIG_NF_NAT=y
CONFIG_NF_NAT_NEEDED=y
CONFIG_IP_NF_TARGET_MASQUERADE=y
CONFIG_IP_NF_TARGET_REDIRECT=y
CONFIG_IP_NF_TARGET_NETMAP=y
CONFIG_NF_NAT_SNMP_BASIC=y
CONFIG_NF_NAT_PROTO_DCCP=y

153. 136
CONFIG_NF_NAT_PROTO_GRE=y
CONFIG_NF_NAT_PROTO_UDPLITE=y
CONFIG_NF_NAT_PROTO_SCTP=y
CONFIG_NF_NAT_FTP=y
CONFIG_NF_NAT_IRC=y
CONFIG_NF_NAT_TFTP=y
CONFIG_NF_NAT_AMANDA=y
CONFIG_NF_NAT_PPTP=y
CONFIG_NF_NAT_H323=y
CONFIG_NF_NAT_SIP=y
CONFIG_IP_NF_MANGLE=y
CONFIG_IP_NF_TARGET_ECN=y
CONFIG_IP_NF_TARGET_TTL=y
CONFIG_IP_NF_TARGET_CLUSTERIP=m
CONFIG_IP_NF_RAW=y
CONFIG_IP_NF_ARPTABLES=y
CONFIG_IP_NF_ARPFILTER=y
CONFIG_IP_NF_ARP_MANGLE=y
#
# IPv6: Netfilter Configuration
#
CONFIG_NF_CONNTRACK_IPV6=m
CONFIG_IP6_NF_QUEUE=y
CONFIG_IP6_NF_IPTABLES=y
CONFIG_IP6_NF_MATCH_RT=y
CONFIG_IP6_NF_MATCH_OPTS=y
CONFIG_IP6_NF_MATCH_FRAG=y
CONFIG_IP6_NF_MATCH_HL=y
CONFIG_IP6_NF_MATCH_IPV6HEADER=y
CONFIG_IP6_NF_MATCH_AH=y
CONFIG_IP6_NF_MATCH_MH=y
CONFIG_IP6_NF_MATCH_EUI64=y
CONFIG_IP6_NF_FILTER=y
CONFIG_IP6_NF_TARGET_LOG=y
CONFIG_IP6_NF_TARGET_REJECT=y
CONFIG_IP6_NF_MANGLE=y
CONFIG_IP6_NF_TARGET_HL=y
CONFIG_IP6_NF_RAW=y
# CONFIG_IP_DCCP is not set
# CONFIG_IP_SCTP is not set
# CONFIG_TIPC is not set
# CONFIG_ATM is not set
# CONFIG_BRIDGE is not set
# CONFIG_VLAN_8021Q is not set
# CONFIG_DECNET is not set
# CONFIG_LLC2 is not set
# CONFIG_IPX is not set
# CONFIG_ATALK is not set
# CONFIG_X25 is not set
# CONFIG_LAPB is not set
# CONFIG_ECONET is not set
CONFIG_WAN_ROUTER=y
CONFIG_NET_SCHED=y
#
# Queueing/Scheduling
#
CONFIG_NET_SCH_CBQ=y
CONFIG_NET_SCH_HTB=y
CONFIG_NET_SCH_HFSC=y
CONFIG_NET_SCH_PRIO=y
CONFIG_NET_SCH_RED=y
CONFIG_NET_SCH_SFQ=y
CONFIG_NET_SCH_TEQL=y
CONFIG_NET_SCH_TBF=y
CONFIG_NET_SCH_GRED=y

154. 137
CONFIG_NET_SCH_DSMARK=y
CONFIG_NET_SCH_NETEM=y
CONFIG_NET_SCH_INGRESS=y
#
# Classification
#
CONFIG_NET_CLS=y
CONFIG_NET_CLS_BASIC=y
CONFIG_NET_CLS_TCINDEX=y
CONFIG_NET_CLS_ROUTE4=y
CONFIG_NET_CLS_ROUTE=y
CONFIG_NET_CLS_FW=y
CONFIG_NET_CLS_U32=y
CONFIG_CLS_U32_PERF=y
CONFIG_CLS_U32_MARK=y
CONFIG_NET_CLS_RSVP=y
CONFIG_NET_CLS_RSVP6=y
CONFIG_NET_CLS_FLOW=y
CONFIG_NET_EMATCH=y
CONFIG_NET_EMATCH_STACK=32
CONFIG_NET_EMATCH_CMP=y
CONFIG_NET_EMATCH_NBYTE=y
CONFIG_NET_EMATCH_U32=y
CONFIG_NET_EMATCH_META=y
CONFIG_NET_EMATCH_TEXT=y
CONFIG_NET_CLS_ACT=y
CONFIG_NET_ACT_POLICE=y
CONFIG_NET_ACT_GACT=y
CONFIG_GACT_PROB=y
CONFIG_NET_ACT_MIRRED=y
CONFIG_NET_ACT_IPT=y
CONFIG_NET_ACT_NAT=y
CONFIG_NET_ACT_PEDIT=y
CONFIG_NET_ACT_SIMP=y
CONFIG_NET_CLS_IND=y
CONFIG_NET_SCH_FIFO=y
#
# Network testing
#
# CONFIG_NET_PKTGEN is not set
# CONFIG_HAMRADIO is not set
# CONFIG_CAN is not set
# CONFIG_IRDA is not set
# CONFIG_BT is not set
# CONFIG_AF_RXRPC is not set
CONFIG_FIB_RULES=y
#
# Wireless
#
# CONFIG_CFG80211 is not set
# CONFIG_WIRELESS_EXT is not set
# CONFIG_MAC80211 is not set
# CONFIG_IEEE80211 is not set
# CONFIG_RFKILL is not set
# CONFIG_NET_9P is not set
#
# Device Drivers
#
#
# Generic Driver Options
#
CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug"
CONFIG_STANDALONE=y
CONFIG_PREVENT_FIRMWARE_BUILD=y
CONFIG_FW_LOADER=y
# CONFIG_DEBUG_DRIVER is not set
# CONFIG_DEBUG_DEVRES is not set

155. 138
# CONFIG_SYS_HYPERVISOR is not set
# CONFIG_CONNECTOR is not set
# CONFIG_MTD is not set
# CONFIG_PARPORT is not set
CONFIG_PNP=y
CONFIG_PNP_DEBUG=y
CONFIG_NETDEVICES=y
CONFIG_NETDEVICES_MULTIQUEUE=y
# CONFIG_IFB is not set
# CONFIG_DUMMY is not set
# CONFIG_BONDING is not set
# CONFIG_MACVLAN is not set
# CONFIG_EQUALIZER is not set
CONFIG_TUN=y
# CONFIG_VETH is not set
# CONFIG_NET_SB1000 is not set
# CONFIG_ARCNET is not set
# CONFIG_PHYLIB is not set
CONFIG_NET_ETHERNET=y
CONFIG_MII=y
CONFIG_HAPPYMEAL=m
CONFIG_SUNGEM=m
CONFIG_CASSINI=m
CONFIG_NET_VENDOR_3COM=y
CONFIG_VORTEX=y
CONFIG_TYPHOON=m
CONFIG_NET_TULIP=y
# CONFIG_DE2104X is not set
CONFIG_TULIP=y
# CONFIG_TULIP_MWI is not set
# CONFIG_TULIP_MMIO is not set
# CONFIG_TULIP_NAPI is not set
# CONFIG_DE4X5 is not set
# CONFIG_WINBOND_840 is not set
# CONFIG_DM9102 is not set
# CONFIG_ULI526X is not set
CONFIG_HP100=m
# CONFIG_IBM_NEW_EMAC_ZMII is not set
# CONFIG_IBM_NEW_EMAC_RGMII is not set
# CONFIG_IBM_NEW_EMAC_TAH is not set
# CONFIG_IBM_NEW_EMAC_EMAC4 is not set
CONFIG_NET_PCI=y
CONFIG_PCNET32=m
CONFIG_AMD8111_ETH=m
CONFIG_AMD8111E_NAPI=y
CONFIG_ADAPTEC_STARFIRE=m
CONFIG_ADAPTEC_STARFIRE_NAPI=y
CONFIG_B44=m
CONFIG_B44_PCI_AUTOSELECT=y
CONFIG_B44_PCICORE_AUTOSELECT=y
CONFIG_B44_PCI=y
CONFIG_FORCEDETH=m
CONFIG_FORCEDETH_NAPI=y
CONFIG_EEPRO100=m
CONFIG_E100=y
CONFIG_FEALNX=m
CONFIG_NATSEMI=m
CONFIG_NE2K_PCI=m
CONFIG_8139CP=y
CONFIG_8139TOO=y
CONFIG_8139TOO_PIO=y
CONFIG_8139TOO_TUNE_TWISTER=y
CONFIG_8139TOO_8129=y
CONFIG_8139_OLD_RX_RESET=y
CONFIG_R6040=m
CONFIG_SIS900=m
CONFIG_EPIC100=m

156. 139
CONFIG_SUNDANCE=m
CONFIG_SUNDANCE_MMIO=y
CONFIG_TLAN=m
CONFIG_VIA_RHINE=m
CONFIG_VIA_RHINE_MMIO=y
CONFIG_VIA_RHINE_NAPI=y
CONFIG_SC92031=m
# CONFIG_NETDEV_1000 is not set
# CONFIG_NETDEV_10000 is not set
# CONFIG_TR is not set
#
# Wireless LAN
#
# CONFIG_WLAN_PRE80211 is not set
# CONFIG_WLAN_80211 is not set
# CONFIG_IWLWIFI_LEDS is not set
CONFIG_WAN=y
# CONFIG_LANMEDIA is not set
# CONFIG_HDLC is not set
# CONFIG_DLCI is not set
# CONFIG_WAN_ROUTER_DRIVERS is not set
# CONFIG_SBNI is not set
# CONFIG_FDDI is not set
# CONFIG_HIPPI is not set
CONFIG_PPP=m
CONFIG_PPP_MULTILINK=y
CONFIG_PPP_FILTER=y
CONFIG_PPP_ASYNC=m
CONFIG_PPP_SYNC_TTY=m
CONFIG_PPP_DEFLATE=m
CONFIG_PPP_BSDCOMP=m
CONFIG_PPP_MPPE=m
CONFIG_PPPOE=m
CONFIG_PPPOL2TP=m
CONFIG_SLIP=m
CONFIG_SLIP_COMPRESSED=y
CONFIG_SLHC=m
CONFIG_SLIP_SMART=y
# CONFIG_SLIP_MODE_SLIP6 is not set
# CONFIG_NET_FC is not set
CONFIG_NETCONSOLE=y
# CONFIG_NETCONSOLE_DYNAMIC is not set
CONFIG_NETPOLL=y
# CONFIG_NETPOLL_TRAP is not set
CONFIG_NET_POLL_CONTROLLER=y
# CONFIG_ISDN is not set
# CONFIG_PHONE is not set
A.2 - Configuração do BIND
options {
directory "/var/bind";
// uncomment the following lines to turn on DNS forwarding,
// and change the forwarding ip address(es) :
//forward first;
//forwarders {
// 123.123.123.123;
// 123.123.123.123;
//};
listen-on-v6 { any; };
//listen-on { 127.0.0.1; };
// to allow only specific hosts to use the DNS server:

157. 140
//allow-query {
// 127.0.0.1;
//};
// if you have problems and are behind a firewall:
//query-source address * port 53;
pid-file "/var/run/named/named.pid";
//transfer-format many-answers;
};
// Briefly, a zone which has been declared delegation-only will be effectively
// limited to containing NS RRs for subdomains, but no actual data beyond its
// own apex (for example, its SOA RR and apex NS RRset). This can be used to
// filter out "wildcard" or "synthesized" data from NAT boxes or from
// authoritative name servers whose undelegated (in-zone) data is of no
// interest.
// See http://www.isc.org/products/BIND/delegation-only.html for more info
//zone "COM" { type delegation-only; };
//zone "NET" { type delegation-only; };
zone "." IN {
type hint;
file "named.ca";
};
zone "localhost" IN {
type master;
file "pri/localhost.zone";
allow-update { none; };
notify yes;
};
zone "127.in-addr.arpa" IN {
type master;
file "pri/127.zone";
allow-update { none; };
notify no;
};
zone "rv6.com.br" IN {
type master;
file "pri/rv6.com.br-internal";
allow-update { none; };
notify yes;
};
# These settings were set by the catalyst build script that automatically
# built this stage.
# Please consult /etc/make.conf.example for a more detailed example.
CFLAGS="-O2 -march=pentium2 -pipe -fomit-frame-pointer"
CXXFLAGS="${CFLAGS}"
# WARNING: Changing your CHOST is not something that should be done lightly.
# Please consult http://www.gentoo.org/doc/en/change-chost.xml before changing.
CHOST="i686-pc-linux-gnu"
MAKEOPTS="-j2"
USE="-X -x11 -alsa -gtk -kde"
=net-misc/dhcpv6-1.0.20 ~x86
$TTL 86400
; Authoritative data for rv6.com.br
;

158. 141
@ IN SOA localhost. rv6.rv6.com.br. (
2004102897 ; Serial (yymmddxx)
10800 ; Refresh 3 hours
3600 ; Retry 1 hour
36000 ; Expire 10 hours
86400 ) ; Minimum 24 hours
IN NS ns1.rv6.com.br.
IN NS ns2.rv6.com.br.
;
;PostMaster para redecomm
;
@ IN MX 10 mail.rv6.com.br.;
;
; Hosts
;
localhost IN A 127.0.0.1
IN HINFO INTEL/110 LINUX
www IN A 192.168.0.1 ;
wwws IN A 201.24.24.30 ;
ns1 IN A 192.168.0.1 ;
ns2 IN A 192.192.192.99 ;
mail IN A 192.192.192.99 ;
arwen IN A 192.192.192.99 ;
gandalf IN A 192.192.192.97 ;
aragorn IN A 192.192.192.98 ;
frodo IN A 192.192.192.96 ;
gollum IN A 192.192.192.94 ;
sauron IN A 192.192.192.95 ;
A.3 - Configuração do Broker
########################## BASIC CONFIGURATION ################################
userid=iesb
passwd=iesbiesb
#
server=broker.freenet6.net
#
# Authentication Method:
#
# auth_method=<{anonymous}|{any|passdss-3des-1|digest-md5|plain}>
#
# anonymous: Sends no username or password
#
# any: The most secure method will be used.
# passdss-3des-1: The password is sent encrypted.
# digest-md5: The password is sent encrypted.
# plain: Both username and password are sent as plain text.
#
# Recommended values:
# - any: If you are authenticating a username / password.
# - anonymous: If you are connecting anonymously.
#
auth_method=any
########################## ROUTING CONFIGURATION ##############################
host_type=router

159. 142
prefixlen=56
if_prefix=eth1
dns_server=200.176.2.10
######################### ADVANCED CONFIGURATION ##############################
gw6_dir=/etc/freenet6
auto_retry_connect=yes
retry_delay=30
keepalive=yes
keepalive_interval=30
#
# Tunnel Encapsulation Mode:
# v6v4: IPv6-in-IPv4 tunnel.
# v6udpv4: IPv6-in-UDP-in-IPv4 tunnel (for clients behind a NAT).
# v6anyv4: Lets the broker choose the best mode for IPv6 tunnel.
# v4v6: IPv4-in-IPv6 tunnel.
#
# Recommended value: v6anyv4
#
tunnel_mode=v6anyv4
#
# Tunnel Interface Name:
# The interface name assigned to the tunnel. This value is O/S dependent.
#
# if_tunnel_v6v4 is the tunnel interface name for v6v4 encapsulation mode
# if_tunnel_v6udpv4 is the tunnel interface name for v6udpv4 encapsulate mode
# if_tunnel_v4v6 is the tunnel interface name for v4v6 encapsulation mode
#
# Default values are set during installation.
#
if_tunnel_v6v4=sit1
if_tunnel_v6udpv4=tun
if_tunnel_v4v6=sit0
# Local IP Address of the Client:
# Allows you to set a specific address as the local tunnel endpoint.
#
# client_v4=<auto|A.B.C.D (valid ipv4 address)>
# client_v6=<auto|X:X::X:X (valid ipv6 address)>
# auto: The Gateway6 Client will find the local IP address endpoint.
#
# Recommended value: auto
#
client_v4=201.45.120.69
client_v6=auto
#
# Script Name:
# File name of the script to run to install the tunnel interface. The
# scripts are located in the template directory under the client
# installation directory.
#
# template=<checktunnel|freebsd|netbsd|openbsd|linux|windows|darwin|cisco|solaris>
#
# Default value is set during installation.
#
template=linux
proxy_client=no

160. 143
############################ BROKER REDIRECTION ###############################
#
# Broker List File Name:
# The 'broker_list' directive specifies the filename where the broker
# list received during broker redirection will be saved.
#
# broker_list=<file_name>
#
broker_list=/tmp/tsp-broker-list.txt
#
# Last Server Used File Name:
# The 'last_server' directive specifies the filename where the address of
# the last broker to which a connection was successfully established will
# be saved.
#
# last_server=<file_name>
#
last_server=/tmp/tsp-last-server.txt
#
# Always Use Last Known Working Server:
# The value of the 'always_use_same_server' directive determines whether the
# client should always try to connect to the broker found in the
# 'last_server' directive filename.
#
# always_use_same_server=<yes|no>
#
always_use_same_server=no
#################################### LOGGING ##################################
log_file=3
log_syslog=3
log_filename=/var/log/gw6c.log
log_rotation=yes
log_rotation_size=32
syslog_facility=USER
# end of gw6c.conf
#------------------------------------------------------------------------------
##### rtadvd.conf made by Gateway6 Client ####
interface eth1
{
AdvSendAdvert on;
AdvOtherConfigFlag on;
prefix 2001:05c0:1101:f300::/64
{
AdvOnLink on;
AdvAutonomous on;
};
};
#!/bin/sh
#
# $Id: linux.sh,v 1.16 2006/09/29 15:28:49 cnepveu Exp $
#
# This source code copyright (c) Hexago Inc. 2002-2006.
#

161. 144
# LICENSE NOTICE: You may use and modify this source code only if you
# have executed a valid license agreement with Hexago Inc. granting
# you the right to do so, the said license agreement governing such
# use and modifications. Copyright or other intellectual property
# notices are not to be removed from the source code.
#
# Note: IPV6 support and tun Support must be enabled before calling this script.
#
LANGUAGE=C
if [ -z $TSP_VERBOSE ]; then
TSP_VERBOSE=0
fi
KillProcess()
{
if [ ! -z $TSP_VERBOSE ]; then
if [ $TSP_VERBOSE -ge 2 ]; then
echo killing $*
fi
fi
PID=`ps axww | grep $1 | grep -v grep | awk '{ print $1;}'`
echo $PID
if [ ! -z $PID ]; then
kill $PID
fi
}
Display()
{
if [ -z $TSP_VERBOSE ]; then
return;
fi
if [ $TSP_VERBOSE -lt $1 ]; then
return;
fi
shift
echo "$*"
}
Exec()
{
if [ ! -z $TSP_VERBOSE ]; then
if [ $TSP_VERBOSE -ge 2 ]; then
echo $*
fi
fi
$* # Execute command
if [ $? -ne 0 ]; then
echo "Error while executing $1"
echo " Command: $*"
exit 1
fi
}
ExecNoCheck()
{
if [ ! -z $TSP_VERBOSE ]; then
if [ $TSP_VERBOSE -ge 2 ]; then
echo $*
fi
fi
$* # Execute command
}

162. 145
# Program localization
Display 1 "--- Start of configuration script. ---"
Display 1 "Script: " `basename $0`
ifconfig=/sbin/ifconfig
route=/sbin/route
ipconfig=/sbin/ip
rtadvd=/usr/sbin/radvd
rtadvd_pid=/var/run/radvd/radvd.pid
sysctl=/sbin/sysctl
rtadvdconfigfilename=gw6c-rtadvd.conf
rtadvdconfigfile=$TSP_HOME_DIR/$rtadvdconfigfilename
if [ -z $TSP_HOME_DIR ]; then
echo "TSP_HOME_DIR variable not specified!;"
exit 1
fi
if [ ! -d $TSP_HOME_DIR ]; then
echo "Error : directory $TSP_HOME_DIR does not exist"
exit 1
fi
#
if [ -z $TSP_HOST_TYPE ]; then
echo Error: TSP_HOST_TYPE not defined.
exit 1
fi
if [ X"${TSP_HOST_TYPE}" = X"host" ] || [ X"${TSP_HOST_TYPE}" = X"router" ]; then
#
# Configured tunnel config (IPv6)
Display 1 "$TSP_TUNNEL_INTERFACE setup"
if [ X"${TSP_TUNNEL_MODE}" = X"v6v4" ]; then
Display 1 "Setting up link to $TSP_SERVER_ADDRESS_IPV4"
if [ -x $ipconfig ]; then
ExecNoCheck $ipconfig tunnel del $TSP_TUNNEL_INTERFACE
ExecNoCheck sleep 1
Exec $ipconfig tunnel add $TSP_TUNNEL_INTERFACE mode sit ttl 64 remote
$TSP_SERVER_ADDRESS_IPV4
else
Exec $ifconfig $TSP_TUNNEL_INTERFACE tunnel ::$TSP_SERVER_ADDRESS_IPV4
fi
fi
Exec $ifconfig $TSP_TUNNEL_INTERFACE up
PREF=`echo $TSP_CLIENT_ADDRESS_IPV6 | sed "s/:0*/:/g" |cut -d : -f1-2`
OLDADDR=`$ifconfig $TSP_TUNNEL_INTERFACE | grep "inet6.* $PREF" | sed -e "s/^.*inet6 addr: //" -
e "s/ Scope.*$//"`
if [ ! -z $OLDADDR ]; then
Display 1 "Removing old IPv6 address $OLDADDR"
Exec $ifconfig $TSP_TUNNEL_INTERFACE inet6 del $OLDADDR
fi
Display 1 "This host is: $TSP_CLIENT_ADDRESS_IPV6/$TSP_TUNNEL_PREFIXLEN"
Exec $ifconfig $TSP_TUNNEL_INTERFACE add
$TSP_CLIENT_ADDRESS_IPV6/$TSP_TUNNEL_PREFIXLEN
Exec $ifconfig $TSP_TUNNEL_INTERFACE mtu 1280
#
# Default route
Display 1 "Adding default route"
ExecNoCheck $route -A inet6 del ::/0 2>/dev/null # delete old default route
ExecNoCheck $route -A inet6 del 2000::/3 2>/dev/null # delete old gw route
Exec $route -A inet6 add ::/0 dev $TSP_TUNNEL_INTERFACE
Exec $route -A inet6 add 2000::/3 dev $TSP_TUNNEL_INTERFACE
fi

163. 146
# Router configuration if required
if [ X"${TSP_HOST_TYPE}" = X"router" ]; then
Display 1 "Router configuration"
Display 1 "Kernel setup"
if [ X"${TSP_PREFIXLEN}" != X"64" ]; then
#Better way on linux to avoid loop with the remaining /48?
$route -A inet6 add $TSP_PREFIX::/$TSP_PREFIXLEN dev $TSP_HOME_INTERFACE 2>/dev/null
fi
Exec $sysctl -w net.ipv6.conf.all.forwarding=1 # ipv6_forwarding enabled
Display 1 "Adding prefix to $TSP_HOME_INTERFACE"
OLDADDR=`$ifconfig $TSP_HOME_INTERFACE | grep "inet6.* $PREF" | sed -e "s/^.*inet6 addr: //" -e
"s/ Scope.*$//"`
if [ ! -z $OLDADDR ]; then
Display 1 "Removing old IPv6 address $OLDADDR"
Exec $ifconfig $TSP_HOME_INTERFACE inet6 del $OLDADDR
fi
Exec $ifconfig $TSP_HOME_INTERFACE add $TSP_PREFIX::1/64
# Router advertisement configuration
Display 1 "Create new $rtadvdconfigfile"
echo "##### rtadvd.conf made by Gateway6 Client ####" > "$rtadvdconfigfile"
echo "interface $TSP_HOME_INTERFACE" >> "$rtadvdconfigfile"
echo "{" >> "$rtadvdconfigfile"
echo " AdvSendAdvert on;" >> "$rtadvdconfigfile"
echo " AdvOtherConfigFlag on;" >> "$rtadvdconfigfile" #habilita o dhcpv6
echo " prefix $TSP_PREFIX::/64" >> "$rtadvdconfigfile"
echo " {" >> "$rtadvdconfigfile"
echo " AdvOnLink on;" >> "$rtadvdconfigfile"
echo " AdvAutonomous on;" >> "$rtadvdconfigfile"
echo " };" >> "$rtadvdconfigfile"
echo "};" >> "$rtadvdconfigfile"
echo "" >> "$rtadvdconfigfile"
/etc/init.d/radvd stop
if [ -f $rtadvdconfigfile ]; then
KillProcess $rtadvdconfigfile
Exec $rtadvd -u radvd -p $rtadvd_pid -C $rtadvdconfigfile
Display 1 "Starting radvd: $rtadvd -u radvd -C $rtadvdconfigfile"
else
echo "Error : file $rtadvdconfigfile not found"
exit 1
fi
fi
Display 1 "--- End of configuration script. ---"
exit 0
A.4 - Configuração do Shorewall
###############################################################################
# /etc/shorewall/shorewall.conf V3.4 - Change the following variables to
# match your setup
#
# This program is under GPL
# [http://www.gnu.org/licenses/old-licenses/gpl-2.0.txt]
#
# This file should be placed in /etc/shorewall
#
# (c) 1999,2000,2001,2002,2003,2004,2005 - Tom Eastep (teastep@shorewall.net)
#
# For information about the settings in this file, type "man shorewall.conf"
#
# Additional information is available at
# http://www.shorewall.net/3.0/Documentation.htm#Conf

164. 147
###############################################################################
# STARTUP ENABLED
###############################################################################
STARTUP_ENABLED=Yes
###############################################################################
# VERBOSITY
###############################################################################
VERBOSITY=2
###############################################################################
# COMPILER
# (setting this to 'perl' requires installation of Shorewall-perl)
###############################################################################
SHOREWALL_COMPILER=shell
###############################################################################
# LOGGING
###############################################################################
LOGFILE=/var/log/messages
##############################################################################
# INTERFACE HANDLERS
#
# We provide two interface handlers presently: ifconfig and iproute2.
# You need one of these to do any kind of network configuration.
# For ifconfig support, emerge sys-apps/net-tools
# For iproute2 support, emerge sys-apps/iproute2
# If you don't specify an interface then we prefer iproute2 if it's installed
# To prefer ifconfig over iproute2
#modules=( "ifconfig" )
# For a static configuration, use something like this
# (They all do exactly the same thing btw)
config_eth0=(
"201.45.120.69/27"
)
config_eth1=(
"192.168.0.1/24"
"fec0:0:0:ffff::1"
"fec0:0:0:ffff::2"
"fec0:0:0:ffff::3"
)
#config_eth0=( "192.168.0.2 netmask 255.255.255.0" )
# Here's how to do routing if you need it
routes_eth0=(
"default via 201.45.120.65" # IPv4 default route
# "10.0.0.0/8 via 192.168.0.1" # IPv4 subnet route
# "::/0" # IPv6 unicast
)

165. 148
A.5 - Configuração do UDHCPd
# Sample udhcpd configuration file (/etc/udhcpd.conf)
# The start and end of the IP lease block
start 192.168.0.20 #default: 192.168.0.20
end 192.168.0.254 #default: 192.168.0.254
# The interface that udhcpd will use
interface eth1 #default: eth0
opt dns 192.168.0.1
option subnet 255.255.255.0
opt router 192.168.0.1
option lease 864000 # 10 days of seconds
A.6 - Configuração do DHCP6s
#
# See dhcp6s.conf(5) man page for details.
#
prefer-life-time 10000;
valid-life-time 20000;
renew-time 5000;
rebind-time 8000;
interface eth1 {
link AAA {
allow unicast;
send unicast;
allow rapid-commit;
server-preference 255;
renew-time 1000;
rebind-time 2400;
prefer-life-time 2000;
valid-life-time 3000;
option dns_servers fe80::250:4ff:fe9f:3ba8;
pool{
range 2001:5c0:a167:0::10 to 2001:5c0:a167:0::101/64;
prefix 2001:5c0:a167:0::/64;
};
};
};
APÊNDICE B

166. 149
B.1 - Lista de Verificação
Lista de Verificação- Migração IPv4 para IPv6 (ANEXO I)
Item Tópico Predecessoras Duração Verificação
WAN
1 Criar conta no Tunnel Broker 1 dia
2 Implantar roteador de borda do túnel 4 dias
3 Configurar o serviço de RA com o prefixo recebido pelo Broker 1; 2; 15 1 dia
LAN (Excessão Firewall)
Geral
4 Levantar firmwares e softwares em producão mapeando os que possuem suporte somente à IPv4 5 dias
5 Dividir firmwares e softwares possuem suporte em duas fases do IPv6 READY (Fase 1 e Fase 2) 4 1 dia
6 Atualizar, os softwares, SO's e firmwares que possuirem atualização de suporte ao IPv6 5 15 dias
7 Habilitar a pilha-dupla e DHCPv6 nos hosts que possuem suporte 3; 20 ; 10; 13; 17 4 dias
8 Verificar sempre atualizações de versionamento e segurança referente ao IPv6 7 1 dia
Especificos
Servidores
DHCPv6
9 Implantar do serviço DHCPv6 e habilitar do IPv6 em sua interface de rede 17 3 dias
10 Inserir o(s) endereços de Link-Local do DNS nos pacote do DHCPv6 9; 12 1 dia
DNSv6
11 Habilitar DNS para suportar IPv6 e habilitar o IPv6 em sua interface de rede 17 1 dia
12 Configurar as zonas Internas para o IPv6 11 1 dia
13 Habilitar endereços na interface IPv6 FC00::1-3 (Site-Local) para uso de equipamentos IPv6 Ready Fase 1 12 1 dia
FIREWALL
14 Habilitar o IPv6 nas interfaces de rede 1 dia
15 Habilitar o roteamento IPv6 e bloquear seu tráfego 14 1 dia
16 Criar de regras no Firewall 1 dia
IPv4
17 Bloquear do protocolo 41 e portas UDP 3544 15 1 dia
IPv6
18 Liberar as portas dos serviços a serem utilizados (basear nos serviços IPv4) 15 1 dia
19 Filtrar o tráfego de tipos ICMPv6 que não são essenciais 15 3 dias
20 Permitir o tráfego de pacote RA para LAN provenientes do roteador de borda (Tunel IPv6 18; 19 1 dia

167. 150
B.2 - Fluxograma

168. 151