O IPv6 - Transição V

10. 464XLAT

Cenário	R6-I4	I4-R6	I6-R4	R4-I6	R6-R4	R4-R6	I6-I4	I4-I6	R6-I4-R6	R4-I6-R4
Suporta	Sim	Não	Não	Não	Sim	Não	Não	Não	Não	Não

O 464XLAT (draft-ietf-v6ops-464xlat-01) é uma solução similar ao dIVI e ao dIVI-pd, que utiliza dupla tradução de IPv4 para IPv6, a fim de oferecer um IPv4 compartilhado para usuários IPv6 nativos. Esta técnica usa uma tradução staless e outra stateful. O tradutor stateless é chamado de CLAT (customer side translator) e faz uma tradução 1:1, ou seja, cada IPv4 possui um IPv6 correspondente. O tradutor stateful é o PLAT (provider side translator) e faz uma tradução 1:N, onde vários IPv6 globais são representados por um IPv4 global para falar com a Internet IPv4.

O funcionamento do 464XLAT é ilustrado nas figuras a seguir:

Figura 32: Diagrama de sequência do 464XLAT

Figura 33: Topologia de rede do 464XLAT

É recomendado que haja um cache DNS implementado no CLAT, capaz de responder as solicitações dos clientes IPv4, fazendo as perguntas ao servidor DNS recursivo do provedor por meio do protocolo IPv6, evitando assim traduções desnecessárias para esse fim.

O uso da tradução stateless na extremidade do usuário e stateful no provedor não é a melhor escolha, se levarmos em consideração os princípios básicos de projeto da Internet. O inverso, como feito no dIVI, ou dIVI-pd, é mais recomendável. Contudo, o 464XLAT não é realmente uma técnica nova, projetada do zero, mas sim uma aplicação inovadora de duas técnicas já padronizadas e relativamente maduras.

O CLAT é uma tradução stateless baseada na RFC 6145 e funciona de maneira semelhante ao IVI, mas utiliza IPv4 privado e não público. A forma como o endereço IPv4 é incluído no endereço IPv6 também é um pouco diferente. A regra de tradução é:

Figura 34: Endereço IPv6 traduzido do IPv4 pelo 464XLAT

Este prefixo XLAT de 96 bits é único por cliente e é atribuído a este pelo provedor do serviço. Como o prefixo utilizado é um /96 a autoconfiguração stateless não é possível e é necessário a utilização de DHCPv6 para a atribuição de endereços. O CLAT pode ser implementado no CPE ou em celulares. Para a implementação em celulares existe um projeto disponível para Android em http://code.google.com/p/android-clat/. Para a implementação em CPE pode-se utilizar o  IVI (http://www.ivi2.org/IVI/), com as configurações adequadas.

Já o PLAT é um NAT64 (RFC 6146) que converte o endereço IPv6 em um dos endereços IPv4 disponíveis no banco de endereços do provedor, para fazer a sua implementação, basta seguir as recomendações feitas na seção anterior.

Testes foram realizados por pelo provedor estadunidense T-Mobile e o pelo Ponto de Troca de Tráfego japonês JPIX, em conjunto com seus participantes. Sua implementação em larga escala está sendo considerada. Os softwares ou implementações do CLAT e XLAT não são vinculadas e diferentes versões de um ou do outro podem ser utilizadas para obter o sistema desejado.

Embora não seja a solução ideal, do ponto de vista técnico, é uma solução que poderá ser usada em larga escala em breve, pois já existem implementações funcionais de seus componentes básicos.  Outro ponto a considerar é que o 464XLAT pode funcionar em conjunto com NAT64, já que o PLAT é um NAT64. Basta acrescentar o DNS64 ao sistema. Usuários podem ser somente IPv6 e usar o NAT64/DNS64 e migrar para a utilização do 464XLAT, acrescentando um CPE que execute a função de CLAT, caso haja, por exemplo, aplicações que não funcionem com o NAT64.

11. 4rd

Cenário	R6-I4	I4-R6	I6-R4	R4-I6	R6-R4	R4-R6	I6-I4	I4-I6	R6-I4-R6	R4-I6-R4
Suporta	Sim	Sim	Não	Não	Não	Não	Não	Não	Não	Sim

O 4rd é uma solução similar ao DS-Lite, no sentido de que usa túneis 4in6 para fornecer IPs versão 4 compartilhados para usuários que já têm IPv6 nativo. Mas, de forma análoga às técnicas de tradução dIVI e 464XLAT, o 4rd é stateless e usa compartilhamento de IPs com restrição de portas.

A técnica foi desenvolvida com base no 6rd, que será estudado mais à frente, e está em processo de padronização, definida atualmente no draft-despres-intarea-4rd-01. Existe uma implementação pública que funciona no vyatta e pode ser encontrada no seguinte URL: http://bougaidenpa.org/masakazu/archives/176. Produtos da linha SEIL do provedor japonês IIJ também implementam o protocolo.

A figura a seguir ilustra uma situação típica de uso do 4rd.

Figura 35: 4rd

É importante considerar que o 4rd, além de distribuir IPs versão 4 compartilhados com A+P, pode também distribuir IPs válidos sem restrição de portas, para cada CPE, além de subredes IPv4.

A figura abaixo representa a forma como os endereços IPv4 e IPv6 são mapeados 1:1, para o caso em que os endereços IPv4 são compartilhados com A+P. Perceba que o mapeamento é stateless:

Figura 36: Tradução de endereços feita pelo 4rd

Para o mapeamento das portas, regras simples foram estabelecidas. As portas baixas, de 0 a 4096, nunca são designadas a um cliente. O tamanho do port-set-ID pode ir de 1 a 15 bits. Os clientes podem receber de 1 a 4 blocos diferentes de portas, de tamanhos variados, conforme o tamanho do port-set-ID. Os 16 bits de cada porta disponível são definidos da seguinte forma:

• 1o. bloco:   0001 + port-set-ID (n=1 a 12 bits) + sufixo (que varia de 0 a 12-n)
• 2o. bloco:   001 + port-set-ID (n=1 a 13 bits) + sufixo (que varia de 0 a 13-n)
• 3o. bloco:   01 + port-set-ID (n=1 a 14 bits) + sufixo (que varia de 0 a 14-n)
• 4o. bloco:   1 + port-set-ID (n=1 a 15 bits) + sufixo (que varia de 0 a 15-n)

Note que se o port-set-ID tiver 15 bits, apenas um bloco estará disponível, se tiver 14 bits, 2 blocos, se tiver 13 bits, 3 blocos, e se tiver de 1 a 12 bits, 4 blocos de portas estarão disponíveis.

A tabela a seguir mostra a quantidade de CPEs possível para cada escolha, assim como a quantidade de portas disponíveis para cada uma, para um mesmo IPv4 compartilhado.

tamanho doport set (bits)	qtd de ID’s(CPEs)	Head=00011o. bloco	Head=0012o. bloco	Head=013o. bloco	Head=14o. bloco	totalde portas	portasnão utilizadas
1	2	2048	4096	8192	16384	30720	4096
2	4	1024	2048	4096	8192	15360	4096
3	8	512	1024	2048	4096	7680	4096
4	16	256	512	1024	2048	3840	4096
5	32	128	256	512	1024	1920	4096
6	64	64	128	256	512	960	4096
7	128	32	64	128	256	480	4096
8	256	16	32	64	128	240	4096
9	512	8	16	32	64	120	4096
10	1024	4	8	16	32	60	4096
11	2048	2	4	8	16	30	4096
12	4096	1	2	4	8	15	4096
13	8192	-	1	2	4	7	8192
14	16384	-	-	1	2	3	16384
15	32768	-	-	-	1	1	32768

Figura 37: Modos de compartilhamento de portas

A configuração dos CPEs pode ser feita manualmente, mas a proposta também define  uma opção de configuração via DHCPv6, que pode ser utilizada.

Assim como as técnicas dIVI e dIVI-pd, a técnica 4rd tem características praticamente ideais para uso por provedores de acesso, por isso seu desenvolvimento e padronização devem ser acompanhados com muita atenção:

• opera com base em redes somente IPv6, que é para onde caminha a Internet;
• utiliza traduções stateless, que são simples de implementar e baratas do ponto de vista computacional, permitindo boa escalabilidade;
• permitem conexões em ambos os sentidos, mantendo a conectividade de fim a fim;
• quando necessário o uso de técnicas statefull, para restrição de portas e compartilhamento via NAT44, isso é feito no lado do usuário, mantendo o princípio de que a complexidade na Internet deve estar na extremidades e não próxima ao core da rede;

12. 6PE e 6VPE

Cenário	R6-I4	I4-R6	I6-R4	R4-I6	R6-R4	R4-R6	I6-I4	I4-I6	R6-I4-R6	R4-I6-R4
Suporta	Não	Não	Não	Não	Não	Não	Não	Não	Sim	Não

Roteamento através de MPLS tem sido largamente utilizado nas redes dos grandes provedores de conectividade Internet. Entretanto, grande parte destes equipamentos já instalados não possuem suporte a IPv6. Dado o alto custo destes equipamentos, pode existir a necessidade de mantê-los em operação. No intuito de resolver este problema pode-se utilizar as técnicas apresentadas neste tópico.

As técnicas em questão são o 6PE e o 6VPE, definidas, respectivamente, nas RFCs 4798 e 4659, que permitem que redes IPv6 estabeleçam a comunicação por meio de um core MPLS IPv4, usando LSPs (Label Switch Paths). Sua implementação utiliza MBGP  (Multiprotocol BGP) sobre IPv4 para se trocar rotas IPv6 e necessita que os PEs (Rot. Borda) sejam Pilha Dupla. Através do MBGP os roteadores de borda recebem as rotas IPv6 mas aplicam MPLS IPv4 sobre os pacotes para realizar o roteamento. Quando o pacote chegar à rede IPv6 de destino, o cabeçalho MPLS é removido e o pacote é encaminhado normalmente através do IPv6.

A diferença entre o 6PE e o 6VPE é que no primeiro caso, os roteadores mantém apenas uma tabela global de roteamento, de forma que o 6PE é mais indicado para provimento de conectividade Internet. Já os roteadores 6VPE são capazes de manter várias tabelas de roteamento separadas logicamente, de forma que a técnica é apropriada para prover serviços de redes privadas (VPNs).

A seguir o diagrama que explica o funcionamento do 6PE.

Figura 38: Topologia de rede 6PE

13. 6rd

Cenário	R6-I4	I4-R6	I6-R4	R4-I6	R6-R4	R4-R6	I6-I4	I4-I6	R6-I4-R6	R4-I6-R4
Suporta	Não	Não	Não	Não	Não	Não	Não	Não	Sim	Não

O 6rd tem o objetivo de permitir ao usuário final ter conexão com as redes IPv6 apesar da rede da operadora continuar funcionando em IPv4. Este tipo de técnica, assim como o 6PE/6VPE, permite que os provedores utilizem a infraestrutura IPv4 já existente para fazer uma implantação rápida do IPv6.

O 6rd (RFC5569) é uma extensão da técnica 6to4, que está em desuso e será melhor explicada item seguinte. O 6rd resolve algumas das limitações técnicas do 6to4, como por exemplo sua assimetria e a falta de controle sobre os relays utilizados, permitindo sua utilização em larga escala.

Para entender o funcionamento do 6rd pode-se observar a figura 39, que ilustra a topologia típica de uso.

Figura 39: Topologia de rede 6rd

Analisando a figura, é possível notar que o 6rd depende basicamente de dois componentes:

• CPE 6rd: instalado como interface entre a rede da operadora e do usuário;
• Relay 6rd: instalado na interface entre a rede IPv4 da operadora e a Internet IPv6.

O CPE 6rd é um CPE tradicional (xDSL modem, cable modem, 3G modem etc), cujo software foi modificado para permitir o uso do 6rd. A necessidade dessa modificação dificulta a implementação da técnica, uma vez que requer a substituição, lógica ou física, de equipamentos em campo. Tal modificação nos CPEs normalmente é viável nos casos em que o provedor gerencia remotamente o equipamento, sendo capaz de fazer upgrades em seu firmware.

O 6rd relay é um equipamento que vai encapsular e desencapsular pacotes para trafegarem corretamente nas redes IPv4 e IPv6.

O CPE 6rd atribui ao usuário um endereço IPv4, como um CPE normal. Entretanto um endereço IPv6 também é atribuído ao usuário. Este endereço IPv6 é um endereço IPv6 público válido, mas é construído de maneira específica para que o relay 6rd identifique-o como um endereço 6rd. O endereço IPv6 atribuído é constituído da seguinte forma:

Figura 40: Tradução de endereço IPv4 para IPv6 no 6rd

No 6rd o tamanho n do prefixo e o tamanho o do endereço IPv4, que formam o prefixo delegado 6rd, são escolhas do provedor de acesso. Para permitir que a autoconfiguração de endereço stateless funcione é necessário que o tamanho deste prefixo n + o seja menor que 64 bits. O ID subrede de tamanho m pode ser definido pela operadora, mas é mais provável que a operadora deixe a definição do valor e tamanho do campo para o usuário final adequar às necessidade de sua rede.

Normalmente utiliza-se n=32, o=32 e m=0. Pode-se, contudo, aumentar o número de bits utilizados por n para além de 32, forçando o endereço IPv4 a utilizar parte dos 64 bits menos significativos, o que impede o funcionamento da autoconfiguração stateless. Para evitar que isto ocorra, o endereço IPv4 pode ocupar menos de 32 bits. Tal configuração é possível se os endereços IPv4 fizerem parte de uma mesma rede, pois pode-se omitir o prefixo da mesma. Por exemplo, se todos os endereços IPv4 forem da rede 198.51.0.0/16, os 16 bits que representam os números 198 e 51 podem ser omitidos e a representação do endereço IPv4 necessitará somente de 16 bits, ao invés dos 32 bits necessários para representar o endereço completo.

O 6rd é uma técnica funcional cuja a implementação em massa foi testada com sucesso no provedor francês Free. Entretanto, a técnica não tem sido adotada por outros, principalmente pela necessidade de atualização do software ou de substituição dos CPEs.

Para configurar o CPE e o roteador de borda com Linux é necessário no mínimo o kernel mínimo 2.6.33 e as configurações para isto são:

Roteador relay 6rd:


ip tunnel add paraDentro mode sit local 203.0.113.1 ttl 64

ip tunnel 6rd dev paraDentro 6rd-prefix 2001:db8::/32

ip link set paraDentro up

ip -6 route add 2001:db8:cb00:7101::/64 dev paraDentro

ip -6 route add 2001:db8::/32 dev paraDentro

ip -6 route add 2000::/3 dev eth1

Roteador CPE 6rd:

ip -6 addr add 2001:db8:cb00:7182::/64 dev eth0

ip tunnel add paraFora mode sit local 203.0.113.130 ttl 64

ip tunnel 6rd dev paraFora 6rd-prefix 2001:db8::/32

ip link set paraFora up

ip -6 addr add 2001:db8:cb00:7182::1/128 dev paraFora

ip -6 route add ::/96 dev paraFora

ip -6 route add 2000::/3 via ::203.0.113.1

Configurando o 6rd com equipamentos Cisco os comandos seriam:

Roteador relay 6rd:

ipv6 general-prefix DELEGATED_PREFIX 6rd Tunnel0
interface Loopback0
ip address 203.0.113.1 255.255.255.0
!
interface Tunnel0
tunnel source Loopback0
tunnel mode ipv6ip 6rd
tunnel 6rd ipv4 prefix-len 8
tunnel 6rd prefix 2001:db8::/32
ipv6 address DELEGATED_PREFIX::/128 anycast
!
ipv6 route 2001:db8::/32 Tunnel0
ipv6 route 2001:db8:cb00:7101::/64 Null0

Roteador CPE 6rd:


ipv6 general-prefix DELEGATED_PREFIX 6rd Tunnel0
interface Dialer0
ip address dhcp  ! (203.0.113.130)
!
interface Tunnel0
tunnel source Dialer0
tunnel mode ipv6ip 6rd
tunnel 6rd ipv4 prefix-len 8
tunnel 6rd prefix 2001:db8::/32
tunnel 6rd br 203.0.113.1
ipv6 address DELEGATED_PREFIX ::/128 anycast
!
interface Ethernet0
ipv6 address DELEGATED_PREFIX ::/64 eui-64
!
ipv6 route 2001:db8::/32 Tunnel0
ipv6 route ::/0 Tunnel0  2001:db8:cb00:7101::
ipv6 route 2001:db8:cb00:7182::/64 Null0

Já para fazer esta configuração em roteadores Juniper é possível encrontrar um exemplo em:

http://www.juniper.net/us/en/local/pdf/implementation-guides/8010078-en.pdf

É importante deixar claro que o 6rd não é uma técnica para ser usada em novos usuários Internet, mas sim para os usuários já existentes, de forma a conseguir uma implantação muito rápida do IPv6. O 6rd funciona com base numa rede IPv4 e não resolve o problema da escassez de endereços. Técnicas escolhidas para novos usuários Internet devem preferencialmente basear-se em redes IPv6 e, quando necessário, preservar endereços IPv4, compartilhando-os.

14. 6to4

Cenário	R6-I4	I4-R6	I6-R4	R4-I6	R6-R4	R4-R6	I6-I4	I4-I6	R6-I4-R6	R4-I6-R4
Suporta	Não	Não	Não	Não	Não	Não	Não	Não	Sim	Não

O 6to4 (RFC 3056) é umas das técnicas de transição mais antigas em uso e é a técnica que inspirou a criação do 6rd. Sua concepção era simples e muito interessante: com ajuda de relays pilha dupla distribuídos na Internet, abertos, instalado de forma colaborativa por diversas redes, qualquer rede IPv4 poderia obter conectividade IPv6, através de túneis 6in4 automáticos.

Por meio do 6to4 qualquer computador com um IPv4 válido poderia funcionar como uma extremidade de um conjunto de túneis automáticos e prover todo um bloco IPv6 /48 para ser distribuído e usado em uma rede.

A técnica funcionou parcialmente e ainda é usada na Internet, mas apresenta diversos problemas. De fato, talvez tenha trazido mais problemas para a implantação do IPv6 de forma geral, do que ajudado.

O 6to4 é composto dos seguintes elementos:

• Relay 6to4: roteador com suporte ao 6to4 e que possui conexão nativa IPv4 e IPv6. Ele funciona como a extremidade dos túneis automáticos para os Roteadores 6to4 que precisam se comunicar com a Internet IPv6. Os relays 6to4 usam o endereço anycast IPv4 192.88.99.1 e anunciam rotas para 2002::/16 através deles, para a Internet.
• Roteador 6to4: roteador que suporta 6to4 que fica na extremidade de uma rede IPv4 e é responsável por trazer conectividade IPv6 para esta rede, por meio dos túneis 6to4.  No caso dos acessos à Internet IPv6, ele direcionará o tráfego até o Relay Router mais próximo, que encaminhará o pacote ao seu destino. Para acesso a outras redes 6to4, os túneis são fechados diretamente com outros Roteadores 6to4.
• Cliente 6to4: equipamento de rede ou computador que usa endereços IPv6 fornecidos pelo túnel 6to4. O cliente 6to4 é um cliente pilha dupla convencional, normalmente numa rede doméstica ou corporativa, que pode usar IPv4 nativo ou compartilhado. O cliente não diferencia um endereço IPv6 obtido via 6to4, de um endereço IPv6 nativo.

As funções de Roteador e Cliente 6to4 podem estar presentes no mesmo equipamento. Um desktop convencional, por exemplo, usando Windows Vista, atua de forma automática como Roteador 6to4, desde que tenha um endereço IPv4 válido disponível.

O endereçamento 6to4, conforme definição da IANA, utiliza o prefixo de endereço global 2002:wwxx:yyzz::/48, onde wwxx:yyzz é o endereço IPv4 público do cliente convertido para hexadecimal. O exemplo a seguir mostra como fazer a conversão de endereços:

Endereço IPv4: 200.192.180.002.

200=C8
192=C0
180=B4
002=02
Com isso, o bloco IPv6 correspondente, via 6to4, é 2002:C8C0:B402::/48.

A figura e tabela abaixo demonstram o fluxo dos pacotes em uma rede 6to4. É importante notar que não existe a necessidade de os pacotes irem e voltarem pelo mesmo relay 6to4. As etapas 1, 3, 4 e 6 utilizam pacotes IPv6 e as etapas 2 e 5 utilizam pacotes IPv6 encapsulados em IPv4 através do protocolo 41.

1 De acordo com a tabela de roteamento, o pacote é enviado através da rede local IPv6 para o roteador R1 utilizando a rota ::/0;

2 O pacote IPv6 é recebido por R1 através da interface LAN, que verifica sua tabela de roteamento e descobre que deve enviar o pacote para a interface virtual 6to4 (rota para a 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). Vamos supor que o pacote foi enviado para o Relay RL1;

3 RL1 recebe o pacote 6to4 através de sua interface IPv4, vê que o pacote utiliza o protocolo 41 e o encaminha para a interface virtual. Esta desencapsula o pacote IPv6 e verifica na sua tabela de roteamento que deve enviá-lo pela interface LAN através do roteador R3, que simplesmente repassa o pacote IPv6 ao servidor S2;

4 S2 responde com o envio de outro pacote IPv6 com destino ao Cliente C2 utilizando a sua rota padrão, que aponta para o roteador R3. R3 recebe o pacote e, através da rota recebida via BGP, sabe que deve enviá-lo para o relay mais próximo, que é RL2;

5 RL2 recebe o pacote IPv6 e verifica que o destino é a rede 6to4 (2002::/16). Deste modo, de acordo com sua tabela de roteamento, ele encaminha o pacote para a interface virtual 6to4, que o empacota em um pacote IPv4 (protocolo 41) e o envia ao endereço IPv4 implícito no endereço IPv6 do destinatário do pacote;

6 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 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.

Figura 41: Topologia e funcionamento do túnel 6to4

Dentre os problemas que afetam o 6to4, pode-se citar problemas de qualidade com relays públicos e problemas de segurança. Alie-se a isso o fato de que diversos sistemas operacionais suportam túneis 6to4 de forma automática, entre eles o Windows XP, o Windows Vista e o Windows 7.  O fato dos sistemas operacionais ativarem os túneis 6to4 sem intervenção ou conhecimento dos usuários traz algumas consequências sérias. Uma delas é que firewalls ou outras medidas de segurança em redes corporativas podem ser inadvertidamente contornadas. Outra, é que, via túnel, os pacotes podem seguir caminhos mais longos, trazendo uma experiência pior para o usuário, em comparação àquela que ele teria se estivesse simplesmente usando IPv4. Um agravante é que não há relays públicos 6to4 no Brasil, ocasionando a ida do pacote para localidades distantes como América do Norte ou Europa, mesmo que a origem e o destino estejam no país.

Provedores de conteúdos e serviços na Internet podem sofrer com a questão, pois ao implantar o IPv6 em um servidor Web, por exemplo, usuários que antes acessavam-no bem via IPv4, podem passar a fazê-lo de forma lenta e instável, via IPv6 obtido automaticamente por meio de um túnel automático 6to4. Isso já foi motivo para adiamento da implantação do IPv6, mas atualizações dos sistemas operacionais têm mudado seu comportamento e o número de usuários potencialmente afetados diminuiu para patamares muito pequenos e aceitáveis.

Ainda assim, é recomendável agir para mitigar esse problema, principalmente porque existe uma medida bastante simples e efetiva, que pode ser utilizada. Deve-se lembrar que o caminho de ida do 6to4 pode ser diferente do caminho de volta. Isto permite que um relay 6to4 seja criado em um servidor Web, ou em uma rede, com o objetivo de responder as requisições recebidas via 6to4. O relay não deve ser público, apenas servirá para responder às requisições dirigidas ao serviço advindas de clientes 6to4. A implementação deste relay não irá reduzir o tempo gasto para receber pacotes 6to4, mas garante que os pacotes 6to4 de resposta saiam da rede com destino ao originador da requisição, já encapsulados em IPv4 e isto dará a vantagem do tempo de resposta ser consideravelmente reduzido, já que não será necessário o pacote ir até o relay localizado no exterior. Esta redução pode melhorar bastante a experiência de acesso de um usuário que utilize 6to4 para acessar um serviço qualquer.

Para implementar este relay é necessário que os roteadores de borda da rede permitam a saída de pacotes com IP de origem 192.88.99.1. Provavelmente isto estará bloqueado por padrão na rede já que este IP não faz parte do bloco a ela designado. É preciso verificar também se o provedor de upstream não está filtrando também esse endereço. Normalmente se a rede em questão for um AS, com bloco próprio, o upstream não terá filtros antispoofing. Caso contrário, terá. Com a liberação do endereço, basta configurar o próprio servidor Web, ou um outro elemento na rede, para fazer o encapsulamento das respostas usando 6to4. No Linux a configuração para isto é:


ip tunnel add tunel6to4 mode sit ttl 64 remote any local 192.88.99.1

ip link set dev tunel6to4 up

ip addr add 192.88.99.1/24 dev lo

ip -6 addr add 2002:c058:6301::/16 dev tunel6to4

ip link set lo up
 

Para redes corporativas, é recomendável bloquear o protocolo 41 para evitar a utilização de túneis automáticos IPv4 pelos usuários. É possível também desabilitar essa função no Windows. Para isso deve ser criada e configurada uma chave de registro, do tipo DWORD:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\tcpip6\Parameters\DisabledComponents

Ao fazer isso, a chave será criada com o valor 0×00. O bit 1 (do menos significativo para o mais significativo) deve ser mudado para 1, para desabilitar o 6to4. Ou seja, o valor da chave deve passar a ser 0×01. A função de todos os bits é descrita a seguir. Note que 0 é o valor padrão e significa que a função está ativa, 1 desativa a função:

bit 0: todos os túneis IPv6, incluindo ISATAP, 6to4 e Teredo;
bit 1: 6to4
bit 2: ISATAP
bit 3: Teredo
bit 4: interfaces IPv6 reais
bit 5: preferência por IPv4 e não IPv6

O 6to4 é, então, um protocolo com histórico importante, mas cujo uso deve ser evitado atualmente. Deve-se desativá-lo em redes corporativas e bloqueá-lo nos firewalls. Contudo, para redes pilha dupla que têm serviços IPv6 públicos na Internet, principalmente servidores Web, é recomendada a instalação de um relay 6to4 para responder a solicitações de usuários externos usando essa tecnologia, mitigando parte dos problemas trazidos pela mesma.

15. Teredo

Cenário	R6-I4	I4-R6	I6-R4	R4-I6	R6-R4	R4-R6	I6-I4	I4-I6	R6-I4-R6	R4-I6-R4
Suporta	Não	Não	Não	Não	Não	Não	Não	Não	Sim	Não

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

Sua utilização não é recomendada, dado que não é muito eficiente, tem alta taxa de falhas e algumas considerações de segurança. Contudo, é importante conhecê-la bem, já que está implementada e é utilizada de forma automática em algumas versões do Windows. A utilização de túneis automáticos implica que, mesmo a rede não tendo IPv6 implantado, usuários podem ter endereços IPv6 em seus dispositivos, inclusive com capacidade para receber conexões entrantes, contornando mecanismos e regras de segurança existentes no ambiente.

Existem dois elementos importantes no Teredo, o Servidor Teredo e o Relay Teredo. A conexão é realizada através de um Servidor Teredo, que a inicia após determinar o tipo de NAT usado na rede do cliente. Em seguida, caso o nó destino possua IPv6 nativo, um Relay Teredo é utilizado para criar uma interface entre o cliente e o nó destino. O Relay utilizado será sempre o que estiver mais próximo do nó destino e não o mais próximo do cliente.

Os Servidores Teredo utilizam a porta UDP 3544 para comunicar-se com os dispositivos. Bloquear pacotes IPv4 enviados de uma rede para a Internet nessa porta e na direção inversa, é uma forma efetiva para evitar a utilização indesejada, muitas vezes involuntária, desse tipo de túneis.

Por padrão, os Windows 7 e Vista já trazem o Teredo instalado e ativado por padrão, enquanto que no Windows XP, 2003 e 2008, ele vem apenas instalado. Quanto ao FreeBSD e ao Linux, ele não vem instalado. Caso seu uso seja desejado é possível utilizar um software chamado miredo.

Para iniciar o túnel, existe uma comunicação entre o cliente e o Servidor Teredo com a finalidade de identificar o tipo de NAT usado na rede. Para isso são usados dois IPs versão 4 no servidor. O Teredo é capaz de funcionar com NAT do tipo Cone, também chamado de NAT Estático e NAT Cone Restrito, também chamado de NAT Dinâmico, mas não funciona com NAT Simétrico. Foge ao escopo deste texto explicar o funcionamento de cada tipo de NAT.

Figura 42: Definição do tipo de túnel Teredo

Uma vez identificado o tipo de NAT, o cliente constrói seu endereço IPv6, conforme a figura a seguir:

Figura 43: Tradução de endereço IPv4 para IPv6 no Teredo

O prefixo é sempre 2001:0000::/32. As Flags servem para identificar o tipo de NAT.

A figura a seguir representa o estabelecimento do túnel Teredo na situação mais complexa possível, quando o cliente está numa rede com NAT Cone Restrito. Note que no estabelecimento do túnel, os primeiros pacotes fluem através do Servidor Teredo. Uma vez estabelecido o túnel, toda a comunicação é feita através do Relay, bidirecionalmente.

Figura 44: Estabelecimento de túnel Teredo

Além de bloquear a porta UDP 3544, para evitar a criação de túneis Teredo, estes podem ser desabilitados no próprio Windows. Para isso deve ser criada e configurada uma chave de registro, do tipo DWORD:


HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\tcpip6\Parameters\DisabledComponents

Ao fazer isso, a chave será criada com o valor 0×00. O bit 2 (do menos significativo para o mais significativo) deve ser mudado para 1, para desabilitar o Teredo. Ou seja, o valor da chave deve passar a ser 0×02. A função de todos os bits é descrita a seguir. Note que 0 é o valor padrão e significa que a função está ativa, 1 desativa a função:

bit 0: todos os túneis IPv6, incluindo ISATAP, 6to4 e Teredo;
bit 1: 6to4
bit 2: ISATAP
bit 3: Teredo
bit 4: interfaces IPv6 reais
bit 5: preferência por IPv4 e não IPv6

Assim como o 6to4, o Teredo possui questões de segurança. Através do encapsulamento ele pode permitir que tráfego que seria bloqueado em IPv4 consiga chegar ao destino. Ele vem instalado e habilitado por padrão no Windows. Recomenda-se que seja desabilitado em redes corporativas

16. ISATAP

Cenário	R6-I4	I4-R6	I6-R4	R4-I6	R6-R4	R4-R6	I6-I4	I4-I6	R6-I4-R6	R4-I6-R4
Suporta	Não	Não	Não	Não	Não	Não	Não	Não	Sim	Não

ISATAP (sigla para Intra-Site Automatic Tunnel Addressing Protocol) é uma técnica de tunelamento que liga dispositivos a roteadores. Sua utilização ocorre dentro das organizações, pois não há um serviço público de ISATAP. É possível utilizar a técnica quando a organização tem IPv6 na extremidade de sua rede, fornecido por seu provedor, mas sua infraestrutura interna, ou parte dela, não suporta o protocolo.

A figura abaixo demonstra o conceito do ISATAP.

Figura 45: Topologia de rede ISATAP

Esta técnica, definida na RFC 5214, é baseada em túneis IPv6 criados automaticamente dentro da rede IPv4 e em endereços IPv6 associados aos clientes de acordo com o prefixo especificado no roteador ISATAP e no IPv4 do cliente. Para a criação destes túneis, são utilizadas as especificações da seção 3 da RFC 4213, que trata do tunelamento através do protocolo IPv4 tipo 41 ou 6in4.

Os endereços IPv4 dos clientes e roteadores são utilizados como parte dos endereços ISATAP, permitindo a um nó determinar facilmente os pontos de entrada e saída dos túneis IPv6, sem utilizar nenhum protocolo ou recurso auxiliar.

O formato do endereço ISATAP segue o seguinte padrão:

Figura 46: Tradução de endereço IPv4 para IPv6 no ISATAP

• Prefixo unicast : É qualquer prefixo unicast válido em IPv6, que pode ser link-local (FE80::/64) ou global. Normalmente utiliza-se uma rede /64 obtida a partir do prefixo global fornecido pelo provedor Internet para uso na rede.
• ID IPv4 público ou privado: Se o endereço IPv4 for público, este campo deve ter 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 será zero;
• ID ISATAP: Sempre tem o valor 5EFE;
• Endereço IPv4: É o IPv4 do cliente ou roteador em formato IPv4;

O ISATAP é suportado pela maior parte dos sistemas operacionais e roteadores e é de fácil implantação.

17. A+P

Cenário	R6-I4	I4-R6	I6-R4	R4-I6	R6-R4	R4-R6	I6-I4	I4-I6	R6-I4-R6	R4-I6-R4
Suporta	Não	Não	Não	Não	Não	Não	Não	Não	Não	Não

Os mecanismos A+P e NAT444, que serão explicados a seguir, não ajudam diretamente na transição de IPv4 para IPv6, mas têm sido usados na tentativa de prolongar a vida útil do IPv4.

Esses mecanismos podem ser usados, contudo, em conjunto com a implantação nativa do IPv6, a fim de garantir conectividade IPv4 para os usuários, numa Internet em transição, onde muitos dos serviços disponíveis ainda são somente IPv4.

A técnica Address Plus Port (A+P), que significa endereço mais porta, está definida na RFC 6346 e compartilha o mesmo endereço público com mais de um usuário, simultaneamente. Para isto ser possível é necessária uma limitação das portas que estarão disponíveis para cada um. É possível fazer a atribuição dos endereços e portas para os diferentes usuários de forma stateless.

O mesmo IPv4 válido é compartilhado entre diversos usuários diferentes.  A CPE é responsável por fazer um NAT na rede do usuário, de forma a atender os dispositivos nela presentes com IPs privados, da RFC 1918, e obedecer a restrição de portas ao fazer a tradução. No caso da implantação em redes com dispositivos móveis, como smartphones, estes devem ser atualizados e estar cientes da restrição de portas.

Esta técnica provavelmente não seria notada por usuários domésticos comuns, pois estes continuariam com IPs válidos e técnicas atuais como STUN ou uPnP para permitir conectividade fim a fim, em conjunto com o NAT na rede do usuário, continuariam funcionando.

A restrição de portas não é, contudo, adequada para serviços corporativos, pois não permitira o uso de servidores em portas padronizadas. O problema pode ser agravado se as portas forem atribuídas de forma dinâmica.

A figura abaixo demonstra o funcionamento do A+P.

Figura 47: Topologia de rede A+P

Exemplos práticos da utilização do A+P já foram dados, nos itens que trataram do DS-Lite com A+P, dIVI e dIVI-pd.

A utilização de A+P, se possível, geralmente é preferível à utilização do NAT444, estudado no item seguinte. É importante lembrar que a utilização dessas técnicas deve ser sempre acompanhada da implantação do IPv6.

18. NAT444

Cenário	R6-I4	I4-R6	I6-R4	R4-I6	R6-R4	R4-R6	I6-I4	I4-I6	R6-I4-R6	R4-I6-R4
Suporta	Não	Não	Não	Não	Não	Não	Não	Não	Não	Não

Assim como o A+P, o NAT444 tem sido usado na tentativa de prolongar a vida útil do IPv4 na Internet. Este mecanismo fere o princípio de comunicação fim a fim da Internet e seu uso deve ser evitado ao máximo. Alternativas que levem as redes na direção de redes somente IPv6 são preferíveis, assim como alternativas que usem métodos stateless e que mantenham a complexidade nas extremidades da rede.

Se usado, o NAT444 deve acompanhar a implantação do IPv6 nativo para os usuários. Não deve ser usado isoladamente.

O NAT444 é descrito no em draft-shirasaki-nat444-05 e também é conhecido como LSN (Large Scale NAT) ou CGN (Carrier Grade NAT). Este mecanismo atribui um IPv4 privado para cada um dos usuários de um ISP, de forma semelhante ao que já é normalmente feito em redes domésticas e em diversas redes corporativas. Ou seja, os usuários conviverão, nesse caso, com duas camadas de NAT.

A utilização desta técnica resolveria, de forma provisória, o problema da falta de endereços IPv4, já que eles seriam largamente reutilizados, mas o custo seria comprometer as conexões fim a fim e possivelmente a “quebra” de diversas aplicações hoje existentes.

Pode-se argumentar que o NAT já é usado normalmente e que não há prejuízo na utilização da Internet por conta disso. Isso não é verdade. O NAT, na rede dos usuários, por si só, já é prejudicial, embora tenha desempenhado um importante papel nos últimos anos para a conservação dos endereços IPv4 na Internet. Técnicas como servidores STUN, uPnP e outras foram desenvolvidas para restaurar, parcialmente, a comunicação fim a fim perdida com uma camada apenas de NAT. Com o uso de NAT444 elas deixarão de funcionar.

Outro ponto a considerar é que essa técnica é cara, exigindo equipamentos com grande poder de processamento. Investimentos altos tendem a ser politicamente conservados dentro de grandes corporações, o que pode levar a um atraso na adoção do IPv6.

Um ponto a considerar, do ponto de vista estritamente técnico, é a escolha do bloco de IPs a ser usado no NAT. Como o uso dos blocos da RFC1918 é comum nas redes dos usuários, qualquer bloco escolhido dentre os disponíveis pelo provedor fatalmente colidirá com o bloco de algum de seus clientes. Existe uma proposta em estudo para a reserva de um novo bloco, exclusivo para a utilização em situações onde houver duplo NAT. O ARIN prontificou-se a ceder o bloco em questão e a proposta está sendo analisada pelo IETF: draft-weil-shared-transition-space-request-15.

Devido ao rapido esgotamento do IPv4, podem existir situações em que essa técnica terá de ser utilizada. Seu uso muitas vezes é incentivado por fabricantes de equipamentos, talvez devido ao alto custo dos equipamentos necessários para sua implementação.

A figura abaixo exemplifica o funcionamento das redes hoje e como ficará o funcionamento da rede com a utilização do NAT444.

Figura 48: Topologia de rede NAT444

19. Considerações Finais

A utilização de pilha dupla IPv4 e IPv6 na Internet foi imaginada com a técnica padrão para uma transição sem solução de continuidade na migração para o IPv6. A pilha dupla parece ser, ainda hoje, a melhor escolha para provedores e redes corporativas, desde que não haja falta de endereços IPv4 válidos e, consequentemente, for possível utilizá-la.

O rápido esgotamento dos endereços IPv4, a existência de equipamentos legados onde não é possível utilizar IPv6 e a presença de equipamentos somente IPv6, por falta de IPs v4 livres, criaram a demanda por outras técnicas de transição. As principais foram apresentadas ao longo deste texto.

Deve-se considerar, ao escolher a técnica a ser usada em uma rede específica, que a Internet caminha para utilizar o IPv6. Não há dúvida de que no futuro a Internet utilizará majoritariamente IPv6 e, possivelmente, somente IPv6. Aqueles que trabalham com redes há pelo menos pouco mais de uma década viveram outras transições similares, como por exemplo, quando, em redes corporativas era comum o uso de IPX/SPX, Netbios, Appletalk e IP concomitantemente. A convergência tecnológica é um processo natural. Ela facilita o gerenciamento das redes, a interoperabilidade, o desenvolvimento de novas aplicações e serviços, reduzindo custos, de forma geral.

Com isso em mente, os provedores devem planejar-se para atender, daqui a pouco tempo, seus novos usuários exclusivamente com redes IPv6, de forma nativa. Devem oferecer paliativamente a eles um IPv4 válido, se houver disponível, ou compartilhado, se necessário. Isso deve ser feito enquanto houver uma quantidade relevante de dispositivos na Internet que não tenham implantado IPv6. Pode-se fazer isso com auxílio de técnicas de transição baseadas em  túneis, ou tradução, usando a rede que será exclusivamente IPv6.

Há muitas técnicas disponíveis. Algumas delas já relativamente maduras e outras em processo de desenvolvimento e padronização. A IETF é uma organização aberta, na qual colaboram provedores Internet, fabricantes de equipamentos, universidades e outros interessados. Ela tem sido muito ágil nesse processo, dada a urgência criada pela necessidade. É importante avaliar cuidadosamente, então, se é preciso investir agora em equipamentos que suportam uma determinada técnica, para serem usados daqui a um ou dois anos, ou se é melhor esperar algum tempo até que tecnologias melhores e mais baratas, do ponto de vista financeiro e computacional, estejam mais maduras. Não é um problema para o qual se possa recomendar soluções em uma direção, ou outra, genericamente. Cada operador ou usuário na Internet deve analisar sua situação específica e escolher dentre as várias opções possíveis, a melhor para seu caso.

Um dos pontos a considerar na escolha das técnicas de transição a serem utilizadas é se elas são stateless ou stateful. Técnicas stateless são preferíveis, dado que escalam melhor e são mais baratas. Se necessário usar técnicas stateful, é preferível que estejam implantadas nos equipamentos dos usuários e não no provedor.

De forma geral, tanto as técnicas de tradução quanto as de túneis forçam a redução do MTU no escopo em que são usados na rede. Embora o presente texto não tenha abordado essa questão, todas elas apresentam mecanismos para contornar esse problema. Contudo, as técnicas baseadas em tradução aparentemente oferecem alguma vantagem, pois não encapsulam o pacote novamente, apenas traduzem e trocam os cabeçalhos na camada IP, o que poderia ser interpretado, grosso modo, como um túnel com compactação do cabeçalho.

O NAT444 é uma técnica a ser evitada. Seu uso não leva a rede do provedor em direção ao IPv6, acarreta altos custos financeiros e dificuldades técnicas para os usuários da Internet. O NAT444 fere o princípio da conexão fim a fim, que foi essencial para o desenvolvimento da Internet nos moldes em que a conhecemos atualmente e é uma das bases que a fazem ser um ambiente propício à inovação, novas idéias, aplicações, serviços e negócios. O compartilhamento de IPs com restrição de portas (A+P) e NAT44 são soluções preferíveis, adotadas em conjunto com túneis ou dupla tradução sobre redes nativas IPv6. NAT 64 em conjunto com DNS 64 e possivelmente ALGs também é uma solução preferível ao NAT444.

Para redes corporativas já existentes, o caminho mais indicado hoje é a implantação do IPv6 de forma gradual, em pilha dupla. Isso deve ser feito de forma urgente nos servidores expostos na Internet, como os servidores Web e de emails e de forma paulatina para os usuários e outros serviços. Ainda há problemas com aplicações utilizadas no dia a dia em relação ao suporte ao IPv6, por isso redes somente IPv6 ainda não podem ser recomendadas de forma genérica. Essa situação, no entanto, vem avançando rapidamente. É possível vislumbrar, já hoje, situações em que os benefícios trazidos pela facilidade de gerenciar uma rede com apenas um protocolo e endereços suficientes para todos os dispositivos, sem a necessidade de traduções, suplantem os problemas advindos da falta de suporte ao IPv6 em algumas aplicações. Pode ser que o futuro em que será vantajoso para as redes corporativas trabalhar apenas com IPv6, com auxílio de técnicas de transição para a comunicação com a Internet IPv4, não esteja muito distante.

Finalmente, deve-se considerar que todas as formas de compartilhamento do IPv4 para usuários geram dificuldades no processo de sua identificação à partir de ações executadas na Internet, caso isso seja necessário. Hoje os provedores Internet normalmente guardam registros, logs, que associam, univocamente, um usuário a um IPv4, dentro de um determinado período de tempo. É comum que em investigações criminais esses logs sejam requisitados, por meio de ordens judiciais, que trazem como dados o IP do usuário e o momento de acesso a um determinado site ou serviço na rede. Com o compartilhamento de IPs não haverá apenas um usuário associado a um IP num dado momento, mas sim diversos. Podem ser alguns poucos, dezenas, ou mesmo centenas. Esse será um problema temporário, resolvido facilmente com a migração dos principais serviços na Internet, como portais de conteúdo, de comércio eletrônico, serviços bancários ou de governo, para IPv6. Paliativamente, no contexto do compartilhamento do IPv4, pode-se propiciar uma possibilidade melhor de identificação, dependendo da técnica utilizada, se como informação for obtido não apenas o IP, mas também a porta de origem, à partir da qual a conexão foi realizada. Dessa forma, para aqueles serviços na Internet que hoje já guardam logs dos IPs de origem dos usuários, como bancos e serviços de comércio eletrônico, é recomendado que passem também a guardar as portas de origem, além de implantarem de forma urgente o IPv6.

20. Referências

1. RFC 1918 - Address Allocation for Private Internets – http://tools.ietf.org/html/rfc1918
2. RFC 2784 - Generic Routing Encapsulation (GRE) – http://tools.ietf.org/html/rfc2784
3. RFC 3053 - IPv6 Tunnel Broker – http://tools.ietf.org/html/rfc3053
4. RFC 3056 - Connection of IPv6 Domains via IPv4 Clouds –http://tools.ietf.org/html/rfc3056
5. RFC 3596 - DNS Extensions to Support IP Version 6 – http://tools.ietf.org/html/rfc3596
6. RFC 4213 - Basic Transition Mechanisms for IPv6 Hosts and Routers –http://tools.ietf.org/html/rfc4213
7. RFC 4291 - IP Version 6 Addressing Architecture – http://tools.ietf.org/html/rfc4291
8. RFC 4659 - BGP-MPLS IP Virtual Private Network (VPN) Extension for IPv6 VPN –http://tools.ietf.org/html/rfc4659
9. RFC 4798 - Connecting IPv6 Islands over IPv4 MPLS Using IPv6 Provider Edge Routers (6PE) – http://tools.ietf.org/html/rfc4798
10. RFC 5211 - An Internet Transition Plan – http://tools.ietf.org/html/rfc5211
11. RFC 5214 - Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) –http://tools.ietf.org/html/rfc5214
12. RFC 5572 - IPv6 Tunnel Broker with the Tunnel Setup Protocol (TSP) –http://tools.ietf.org/html/rfc5572
13. RFC 5569 - IPv6 Rapid Deployment on IPv4 Infrastructures (6rd) –http://tools.ietf.org/html/rfc5569
14. RFC 6052 - IPv6 Addressing of IPv4/IPv6 Translators – http://tools.ietf.org/html/rfc6052
15. RFC 6144 - Framework for IPv4/IPv6 Translation – http://tools.ietf.org/html/rfc6144
16. RFC 6145 - IP/ICMP Translation Algorithm – http://tools.ietf.org/html/rfc6145
17. RFC 6146 - Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers – http://tools.ietf.org/html/rfc6146
18. RFC 6147 - DNS64: DNS Extensions for Network Address Translation from IPv6 Clients to IPv4 Servers – http://tools.ietf.org/html/rfc6147
19. RFC 6219 - The China Education and Research Network (CERNET) IVI Translation  Design and Deployment for the IPv4/IPv6 Coexistence and Transition –http://tools.ietf.org/html/rfc6219
20. RFC 6333 - Dual-Stack Lite Broadband Deployments Following IPv4 Exhaustion –http://tools.ietf.org/html/rfc6333
21. RFC 6346 - The Address plus Port (A+P) Approach to the IPv4 Address Shortage –http://tools.ietf.org/html/rfc6346
22. draft-bcx-behave-address-fmt-extension - Extended IPv6 Addressing for Encoding Port Range – http://tools.ietf.org/html/draft-bcx-behave-address-fmt-extension-01
23. draft-despres-intarea-4rd-01 - IPv4 Residual Deployment across IPv6-Service networks (4rd) ISP-NAT’s made optional – http://tools.ietf.org/html/draft-despres-intarea-4rd-01
24. draft-ietf-v6ops-464xlat-01 - 464XLAT: Combination of Stateful and Stateless Translation – http://tools.ietf.org/html/draft-ietf-v6ops-464xlat-01
25. draft-ietf-v6ops-happy-eyeballs-07 - Happy Eyeballs: Success with Dual-Stack Hosts –http://tools.ietf.org/html/draft-ietf-v6ops-happy-eyeballs-07
26. draft-massar-v6ops-ayiya-02 - AYIYA: Anything In Anything –http://tools.ietf.org/html/draft-massar-v6ops-ayiya-02
27. draft-shirasaki-nat444-05 - NAT444 – http://tools.ietf.org/html/draft-shirasaki-nat444-05
28. draft-weil-shared-transition-space-request-15 - IANA Reserved IPv4 Prefix for Shared Address Space – http://tools.ietf.org/html/draft-weil-shared-transition-space-request-15
29. draft-xli-behave-divi-04 - dIVI: Dual-Stateless IPv4/IPv6 Translation –http://tools.ietf.org/html/draft-xli-behave-divi-04
30. draft-xli-behave-divi-pd-01 - dIVI-pd: Dual-Stateless IPv4/IPv6 Translation with Prefix Delegation – http://tools.ietf.org/html/draft-xli-behave-divi-pd-01
31. http://www.iana.org/assignments/ethernet-numbers
32. http://tunnelbroker.net/
33. http://www.sixxs.net/main/
34. http://www.tunnelbroker.net/forums/index.php?topic=1016.0
35. http://wiki.openwrt.org/doc/uci/network#dynamic.ipv6-in-ipv4.tunnel.he.net.only
36. http://www.isc.org/software/aftr
37. http://www.kangaroo.comcast.net/wiki/doku.php?id=wrt54gl:wrt54gl
38. http://www.litech.org/tayga/
39. http://sourceforge.net/projects/linuxnat64/
40. http://www.juniper.net/techpubs/en_US/junos10.4/information-products/topic-collections/nce/nat64-ipv6-ipv4-depletion/configuring-nat64-ipv6-ipv4-depletion.pdf
41. http://www.isc.org/software/bind
42. http://www.dillema.net/software/totd.html
43. http://code.google.com/p/android-clat/
44. http://www.ivi2.org/IVI/
45. http://bougaidenpa.org/masakazu/archives/176
46. http://www.juniper.net/us/en/local/pdf/implementation-guides/8010078-en.pdf
47. http://ecdysis.viagenie.ca/

Técnicas de Transição do IPv4 para o IPv6 – NIC.br – http://ipv6.br -  rev.2012.04.10-01