• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
I pv4para ipv6-final
 

I pv4para ipv6-final

on

  • 5,926 views

This document aims to be a practical migration reference to the IPv6...

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.

Statistics

Views

Total Views
5,926
Views on SlideShare
5,911
Embed Views
15

Actions

Likes
8
Downloads
0
Comments
0

4 Embeds 15

http://www.linkedin.com 10
http://static.slidesharecdn.com 2
http://www.techgig.com 2
https://www.linkedin.com 1

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    I pv4para ipv6-final I pv4para ipv6-final Document Transcript

    • 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
    • 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
    • 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.
    • 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
    • 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
    • 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.
    • 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.
    • 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
    • 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
    • x LISTA DE TABELAS Tabela 4.1 – Cenários para implantação de redes ................................................... 72 Tabela 4.2 – Configuração dos Ativos ...................................................................... 73
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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;
    • 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.
    • 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
    • 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
    • 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.
    • 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
    • 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
    • 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
    • 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.
    • 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
    • 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:
    • 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
    • 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
    • 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
    • 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.
    • 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”.
    • 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
    • 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)
    • 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”
    • 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
    • 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.
    • 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
    • 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
    • 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.
    • 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
    • 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.
    • 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.
    • 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).
    • 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.
    • 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
    • 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,
    • 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;
    • 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
    • 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:
    • 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;
    • 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.
    • 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.
    • 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
    • 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
    • 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;
    • 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
    • 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
    • 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:
    • 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
    • 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:
    • 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
    • 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
    • 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.
    • 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:
    • 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:
    • 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;
    • 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.
    • 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:
    • 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
    • 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
    • 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
    • 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
    • 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:
    • 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
    • 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
    • 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
    • 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
    • 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,
    • 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
    • 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.
    • 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
    • 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.
    • 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
    • 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.
    • 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.
    • 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.
    • 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.
    • 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
    • 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
    • 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.
    • 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
    • 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
    • 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
    • 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
    • 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.
    • 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.
    • 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:
    • 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
    • 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
    • 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
    • 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 .
    • 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
    • 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
    • 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.
    • 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
    • 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
    • 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:
    • 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):
    • 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
    • 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-
    • 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
    • 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.
    • 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
    • 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
    • 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
    • 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.
    • 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
    • 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.
    • 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
    • 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.
    • 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.
    • 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).
    • 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:
    • 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.
    • 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
    • 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
    • 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
    • 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á
    • 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.
    • 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.
    • 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
    • 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
    • 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.
    • 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
    • 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.
    • 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.
    • 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.
    • 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
    • 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.
    • 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.
    • 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,
    • 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.
    • 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.
    • 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.
    • 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.
    • 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.
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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:
    • 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 ;
    • 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
    • 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
    • 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. #
    • 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 }
    • 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
    • 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
    • 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 )
    • 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
    • 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
    • 150 B.2 - Fluxograma
    • 151