Existe mais de uma possibilidade de transportar pacotes IPvb6 em links IPv4. Show
9.1.1. Túnel estático ponto a ponto: 6boneUm túnel ponto a ponto é um túnel dedicado em direção a um ponto final., o qual sabe informações sobre uma rede IPv6A (para rotas de volta) e os endereços IPv4 deste túnel estão definidos na RFC 2893 / Transition Mechanisms for IPv6 Hosts and Routers. Necessidades:
9.1.2. Túnel automáticoUm túnel automático acontece quando um nó diretamente conectado a outro nó obtém um IPv4 do outro nó anterior. 9.1.3. 6to4-TunnelingO túnel 6to4 (RFC 3056 / Connection of IPv6 Domains via IPv4 Clouds) utiliza um mecanismo simples para criar túneis automáticos. Cada nó com um endereço global único é capaz de ser uma ponta final de um túnel 6to4 (se nenhum firewall no meio do caminho bloquear este tipo de tráfego). Túneis 6to4 não costumam ser túneis um a um. Este tipo de túnel pode ser dividido em Upstream e Downstream. Além disso, um endereço especial IPv6 indica que este nó vai usar o tunelamento 6to4 para se conectar a redes IPv6 mundiais. 9.1.3.1. Geração de prefixo 6to4O endereço 6to4 está definido abaixo (o esquema foi pego da RFC 3056 / Connection of IPv6 Domains via IPv4 Clouds): | 3+13 | 32 | 16 | 64 bits | +---+------+-----------+--------+--------------------------------+ | FP+TLA | V4ADDR | SLA ID | Interface ID | | 0x2002 | | | | +---+------+-----------+--------+--------------------------------+ FP e TLA juntos (16 bits) tem o valor 0x2002. V4ADDR é o endereço único IPv4 (em notação hexadecimal). SLA é o identificador de rede (65536 redes locais possíveis) e são usados para representar a sua estrutura de rede local. Para os gateways, tal prefixo é gerado normalmente usando o SLA ”0000” e o sufixo "::1" (não é uma exigencia, pode ser arbitrário com um escopo local) e então assinalado a uma interface de túnel 6to4. Veja que a Microsoft também utiliza V4ADDR para o sufixo. 9.1.3.2. Tunelamento Upstream 6to4O nó tem que saber para qual ponta remota de túnel os pacotes IPv4 com pacotes IPv6 devem ser encaminhados. No início dos tempos de tunelamento 6to4, upstreams dedicados aceitavam que os routers fizessem isso. Veja NSayer's 6to4 information para uma lista de routers. Hoje em dia, os routers upstream 6to4 podem ser encontrados automaticamente, usando o endereço de unicast 192.88.99.1. Os protocolos de roteamento se incumbem desta função, veja RFC 3068 / An Anycast Prefix for 6to4 Relay Routers para mais detalhes. 9.1.3.3. Tunelamento Downstream 6to4O downstream (6bone -> seu nó com 6to4 habilitado) não é realmente correto e pode variar de um host remoto estranho que originou os pacotes que foram enviados a voce. Existem duas possibilidades:
9.1.3.4. Tráfego 6to4 possível
Rede IP I: Processos de Migração – 1 Processos de uma Migração – Coexistência IPv4/IPv6 e Suporte – Parte 1 Esta seção apresenta 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. 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 estar-se-á 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:
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. 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:
Apesar de, num futuro próximo, ser possível ter redes totalmente IPv6, o mais comum será ter IPv4 e IPv6 na mesma infraestrutura. E, para permitir isto, são necessários ferramentas e mecanismos de coexistência e integração (SILVIA, 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).  Figura 12: 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 infraestrutura, 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 infraestrutura IPv6. 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 13: Tráfego de pacotes com a arquitetura de pilha dupla 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. 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 na 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. 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, 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:
Figura 14: Configuração Host a Host
Figura 15: Configuração Host a Roteador
Figura 16: Configuração Roteador a Roteador 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. Figura 17: 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 mecanimos genéricos de encapsulamento. Há, também, mecanismos de criação semiautomá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: Túneis ISATAP O tipo de tunelamento Intra-Site Automatic Tunnel Addressing Protocol (ISATAP), tem sua fundamentação emtú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 18: Estrutura de pacote ISATAP Figura 19: Topologia utilizando túnel ISATAP A figura 18 mostra a estrutura de um pacote ISATAP, onde:
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. Modelo de comunicação ISAPTAP Para a criação do túnel ISATAP, o processo de inicialização é descrito nos passos a seguir:
Figura 20: 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:
Figura 21: 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 22: Comunicação entre máquinas com ISATAP configurada em diferentes segmentos de rede 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:
Figura 23: Comunicação entre máquinas com ISATAP – diferentes segmentos de rede IPv6 Segurança de Túnel ISATAP Os pontos negativos em relação ao ISATAP são:
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 24: 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:
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: Figura 25: Estrutura da conexão 6to4 Os possíveis hosts que fazem parte desse cenário serão explicados abaixo:
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: Figura 26: Comunicação do túnel 6to4
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. 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: Figura 27: Comunicação relay/roteador 6to4 com servidor IPv6
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:
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. 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:
Estes elementos e suas interações estão bem detalhados na figura abaixo: Figura 28: 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: Figura 29: Inicialização do túnel Broker
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). 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:
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:
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. 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 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-Simetrico), 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-Simetrico, 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 serviço. Assim, o suporte ao NAT-Simetrico 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 30: Configuração Teredo
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: Figura 31: Conexão Teredo com NAT do tipo restrito
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 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:
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. 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 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. Pode usar IPv4 e IPv6 juntos?Para redes corporativas que já utilizam NAT isso não é um impendimento: o IPv6 nativo pode ser utilizado em conjunto com o IPv4 compartilhado.
Qual a importância do IPv6 em relação ao IPv4?A disponibilidade de um número quase ilimitado de endereços IP é um dos maiores benefícios da implementação de redes IPv6. Comparado ao IPv4, o IPv6 aumenta o número de bits do endereço por um fator 4. Desta forma, o endereço que na versão 4 era de 32 bits, passa a ter 128 bits.
Qual a principal razão da transição de IPv4 para IPv6?O esgotamento do IPv4 e a necessidade de mais endereços na Internet. O principal motivo para a implantação do IPv6 na Internet é a necessidade de mais endereços, porque a disponibilidade de endereços livres IPv4 terminou.
Qual é a técnica de coexistência e transição do IPv6 para IPv4?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.
|
Por que usar tunelamento para IPv6 com o IPv4?
Postagens relacionadas
direito autoral © 2024 membukakan Inc.
