Túneis Teredo

Escrito por Ailton Soares Rocha e Rodrigo Regis dos Santos

Introdução

A técnica de tunelamento automática Teredo, definida na RFC 4380, permite que nós localizados atrás de Network Address Translations (NAT), obtenham conectividade IPv6 utilizando o protocolo UDP.

A conexão é realizada através de um Servidor Teredo que a inicializa, e determinar o tipo de NAT usada pelo cliente. Em seguida, caso o host de destino possua IPv6 nativo, um Relay Teredo é utilizado para criar uma interface entre o Cliente e o host de destino. O Relay utilizado será sempre o que estiver mais próximo host de destino, e não o mais próximo ao cliente.

Esta técnica não é muito eficiente devido ao overhead e a complexidade de seu funcionamento, entretanto, quando o host está atrás de NAT, ela é uma das únicas opções.

Por padrão, o Windows Vista já traz o Teredo instalado e ativado, enquanto que no Windows XP, 2003 e 2008, ele vem apenas instalado. Quanto ao Freebsd e ao Linux, ele não vem instalado.

A comunicação neste tipo de túnel é realizada da seguinte forma:

Primeiramente, é necessário que o Servidor Teredo possua dois endereços IPv4 públicos (primário e secundário). Além disso, o Cliente Teredo deve definir seu endereço IPv6 e o tipo de NAT que está entre ele e a Internet IPv4. Para isso, são executados os seguintes passos:

1. Uma mensagem Router Solicitation (RS) é enviada ao Servidor Teredo endereçada ao IPv4 primário com o flag de NAT tipo Cone ativado. Então o Servidor Teredo responde com uma mensagem de Router Advertisement (RA). Como a mensagem RS estava com o Cone flag ativado, o Servidor Teredo envia a mensagem RA utilizando seu endereço IPv4 secundário. Com isso, se ele receber a mensagem de RA, o Cliente conseguirá determinar se o NAT que ele está utilizando é do tipo Cone Full;
2. Se a mensagem RA do passo anterior não for recebida, o Cliente Teredo envia uma outra mensagem Router Solicitation (RS), mas agora, com o Cone flag desativado. O Servidor Teredo responde novamente com uma mensagem RA, porém, como o Cone flag da mensagem RS estava desativado, ele responde utilizando o mesmo endereço IPv4 em que ele recebeu a mensagem RS. Se agora o Cliente receber a mensagem de RA, então ele conclui que está utilizando NAT do tipo Cone Restrito;
3. Para ter certeza de que o Cliente Teredo não está utilizando um NAT do tipo simétrico, ele envia mais uma mensagem Router Solicitation (RS), mas agora, endereçada ao IPv4 secundário do Servidor Teredo, que responde com uma mensagem do tipo RA. Quando o Cliente recebe a mensagem RA do Servidor Teredo, ele compara o endereço e a porta UDP de origem contidos na mensagem RA recebidas dos dois IPs, se forem diferentes o cliente conclui que está utilizando NAT do tipo simétrico, que não é compatível com o Teredo.

Baseado nas mensagens RA recebidas dos Servidores, o cliente constrói seu endereço IPv6, utilizando o seguinte padrão:

Estrutura do endereço TEREDO.

• Os Bits 0 a 31 são o prefixo do Teredo recebido do Servidor através das mensagens RA; o padrão é 2001:0000;
• OS Bits 32 a 63 são o endereço IPv4 primário do Servidor Teredo que enviou a primeira mensagem RA;
• Os Bits 64 a 79 são utilizados para definir alguns flags. Normalmente, somente o bit mais significativo é utilizado, sendo que ele é marcado como 1 se o Cliente está atrás de NAT do tipo Cone, caso contrário ele é marcado como 0. Apenas o Windows Vista e Windows Server 2008 utilizam todos os 16 bits, que seguem o formado "CRAAAAUG AAAAAAAA", onde "C" continua sendo a flag Cone; o bit R é reservado para uso futuro; o bit U define a flag Universal/Local (o padrão é 0); o bit G define a flag Individual/Group (o padrão é 0); e os 12 bits “A” são randomicamente determinados pelo Cliente para introduzir uma proteção adicional ao nó contra ataques de scan;
• Os Bits 80 a 95 são a porta UDP de saída do NAT, recebida nas mensagens RA e mascarada através da inversão de todos os seus bits. Este mascaramento é necessário porque alguns NATs procuram portas locais dentro dos pacotes e os substituem pela porta pública ou vice-versa;
• Os Bits 96 a 127 são o endereço IPv4 público do Servidor NAT, mascarado através da inversão de todos os seus bits. Este mascaramento é necessário porque alguns NATs procuram endereços IPs locais dentro dos pacotes e os substituem pelo endereço público ou vice-versa.

Para manter a definição inicial (porta UDP utilizada no NAT e IPv4 do Servidor Teredo), o Cliente envia pacotes (bubles) periodicamente ao Servidor (o padrão é a cada 30s). Estes pacotes são descartados pelo Servidor, que em seguida, envia uma resposta ao cliente, mantendo o mapeamento feito inicialmente no NAT.

Última atualização 09/10/2008 13h15

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