Técnica de transição

Escrito por Rodrigo Regis dos Santos

Tradução

As técnicas de tradução possibilitam um roteamento transparente na comunicação entre nós que apresentem suporte apenas a uma versão do protocolo IP, ou utilizem pilha dupla. Estes mecanismos podem atuar de diversas formas e em camadas distintas, traduzindo cabeçalhos IPv4 em cabeçalhos IPv6 e vice-versa, realizando conversões de endereços, de APIs de programação, ou atuando na troca de trafego TCP ou UDP.

Os principais mecanismos de tradução utilizados são:

• SIIT (Stateless IP/ICMP Translation Algorithm) - definido na RFC 2765, o SIIT é um mecanismo de tradução stateless de cabeçalhos IP/ICMP, permitindo a comunicação entre nós com suporte apenas ao IPv6 com nós que apresentam suporte apenas ao IPv4. Ele utiliza 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 nó IPv6. Quando o pacote chega ao SIIT, o cabeçalho é traduzido, convertendo o endereço para IPv4 e encaminhado ao nó de destino;

• NAT-PT (Network Address Translation with Protocol Translation) - este mecanismo, definido na RFC 2766, permite a comunicação de hosts IPv6 com hosts IPv4 combinando métodos de tradução de cabeçalho e conversão de endereço. Seu funcionamento acontece da seguinte forma: um host IPv6 envia um pacote ao gateway NAT-PT, que mapeia o endereço do host para um endereço IPv4 público, traduz o protocolo IPv6 para IPv4 e envia o pacote ao host IPv4 de destino. Ao enviar o pacote ao gateway, o host IPv6 deve adicionar um prefixo pré-configurado ::/96 ao endereço IPv4 do destino, visto 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). O DNS-ALG permite o mapeamento de nomes para endereços IPv6, sendo capaz de traduzir endereços IPv6 em queries e respostas DNS para o endereço IPv4 especificado e vice-versa, transmitindo pacotes DNS entre as redes IPv6 e IPv4;

• NAPT-PT (Network Address Port Translation and Packet Translation) - também definido na RFC 2766, este mecanismo possibilita a comunicação entre hosts IPv6 e IPv4 de forma transparente, utilizando apenas um único endereço IPv4. Seu funcionamento consiste em traduzir 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. Um exemplo do uso desse mecanismo pode ser como se segue:

No exemplo acima, todas as sessões que chegam ao NAPT-PT com a porta 80 como destino serão redirecionadas para o host A. Importante destacar também, que o NAPT-PT é sempre unidirecional, ou seja, somente hosts IPv6 iniciam sessões com os hosts IPv4;

• BIS (Bump in the Stack) - esse método possibilita a comunicação de aplicações IPv4 com nós IPv6. Definida na RFC 2767, o BIS funciona entre a camada de aplicação e a de rede, adicionando à pilha IPv4 três módulos: translator, que traduz os cabeçalhos IPv4 enviados em cabeçalhos IPv6 e os cabeçalhos IPv6 recebidos em cabeçalhos IPv4; extension name resolver, que atua nas DNS queries realizadas pelo IPv4, de modo que, se o servidor DNS retorna um registro AAAA, o resolver pede ao address mapper para atribuir um endereço IPv4 correspondente ao endereço IPv6; e address mapper, que possui uma certa quantidade de endereços IPv4 para associar a endereços IPv6 quando o translator receber um pacote IPv6. Como os endereços IPv4 não são transmitidos na rede, eles podem ser endereços endereços privados. Esse método permite apenas a comunicação de aplicações IPv4 com hosts IPv6, e não o contrário, além de não funcionar em comunicações multicast;

Bump in the Stack

• BIA (Bump in the API) - similar ao BIS, esse mecanismo adiciona uma API de tradução entre o socket API e os módulos TPC/IP dos hosts de pilha dupla, permitindo a comunicação de aplicações IPv4 com hosts IPv6, traduzindo as funções do socket IPv4 em funções do socket IPv6 e vice-versa. Conforme descrito na RFC 3338, três módulos são adicionados, extension name resolver e address mapper, que funcionam da mesma forma que no BIS, e o function mapper, que detecta as chamadas das funções do socket IPv4 e invoca as funções correspondentes do socket IPv6 e vice-versa. O BIA apresenta duas vantagens em relação ao BIS: não depender do driver da interface de rede e não introduzir overhead na tradução dos cabeçalhos dos pacotes. No entanto, ele também não suporta comunicações multicast;

Bump in the API

• TRT (Transport Relay Translator) - atuando como um tradutor de camada de transporte, esse mecanismo possibilita a comunicação entre hosts apenas IPv6 e hosts apenas IPv4 através de trafego TCP/UDP. Sem a necessidade de se instalar qualquer tipo de software, o TRT roda em máquinas com pilha dupla que devem ser inseridas em um ponto intermediário dentro da rede. Na comunicação de um host IPv6 com um host IPv4, conforme definição na RFC 3142, é adicionado um prefixo IPv6 falso ao endereço IPv4 do destino. Quando um pacote com esse prefixo falso passa pelo TRT, esse pacote é interceptado e enviado ao host IPv4 de destino em um pacote TCP ou UDP. Na tradução TCP e UDP o checksum deve ser recalculado e apenas no caso das conexões TCP, o estado do socket sobre o qual o host está conectado deve ser mantido, removendo-o quando a comunicação for finalizada. Para que o mecanismo funcione de forma bidirecional, é necessário a adição de um bloco de endereços IPv4 públicos e o uso de um servidor DNS-ALG para mapear os endereços IPv4 para IPv6;

• SOCKS64 (Socks-Based IPv6/IPv4 Gateway) - baseado no proxy SOCKS convencional, esse mecanismo é composto por um gateway SOCKS implementado como um host com pilha dupla IPv4/IPv6 e um host cliente implementado com um software chamado SOCKS LIB entre as camadas de aplicação e transporte. Esse software intercepta as pesquisas DNS e as responde com endereços IPv4 falsos, de modo que, quando o cliente realiza uma chama a API de conexão, o SOCKS LIB substitui o endereço falso pelo original e envia o pacote, chamado de socksified, para o proxy que executa a pesquisa DNS real. Se o servidor DNS responder com um registro AAAA, o proxy abre um socket IPv6, caso contrário, será aberto um socket IPv4. Definido na RFC 3089, o SOCKS64 é uma solução bidirecional, permitindo que tanto hosts IPv4 quanto hosts IPv6 iniciem sessões. Entretanto, é necessário que se utilize endereços IPv4 públicos;

• ALG (Application Layer Gateway) - trabalha como um proxy HTTP, onde o cliente primeiramente inicia a conexão com o ALG, que, então, estabelece uma conexão com o servidor, retransmitindo as requisições de saída e os dados de entrada. Em redes apenas IPv6, o ALG habilita a comunicação dos hosts com serviços em redes apenas IPv4, configurando o ALG em nós com pilha dupla. Este tipo de mecanismo e normalmente utilizado quando o host que deseja acessar a aplicação no servidor IPv4, está atrás de NAT ou de um firewall.

Última atualização 24/10/2008 16h32

   Licença:  Creative Commons Atribuição 2.5 Brasil (salvo seja especificada outra)     Válido:  XHTML 1.0 -  CSS 3