Seção: Banda Larga
|
|
||
Processos de uma Migração – Coexistência IPv4/IPv6 e Suporte – Parte 2
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 um dos métodos tratados na literatura, segue uma explanação dos principais mecanismos.
Mecanismos de Tradução
Stateless 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 (RFC 2765, 2000).
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 (RFC 2766, 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, desenvolvendo um gateway DNS-Application Level Gateway (DNS-ALG) (RFC 2766, 2000).
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 (RFC 2766, 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.
Problemas Adicionais de Segurança em IPv6
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.
Router Advertisement e Neighbor Discorvery
O Router Advertisement (RA), assim como o protocolo Neighbor 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 à 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.
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 enderç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.
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 foram determinado os requisitos para a obtenção desse nível de logo. Todos os requisitos necessários para a obtenção das 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.
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 Fase1 e Fase 2. A Fase 1 é composta de 170 testes distintos dentro das capacidades do IPv6.
Figura 32: Logo Silver Fase I
Os requisitos para a obtenção dessa Logo são:
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 33: 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:
Nas seções Processo de Migração partes 1 e 2 foram apresentadas algumas das formas de coexistências entre as duas versões do protocolo IP e o funcionamento destas interações. No tutorial parte II 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.
|