Leandro Cesari Maschietto: Transição IPV6

Introdução

O IPv4 e o IPv6 não são diretamente compatíveis entre si. O IPv6 não foi projetado para ser uma extensão, ou complemento, do IPv4, mas sim, um substituto que resolve o problema do esgotamento de endereços. Embora não interoperem, ambos os protocolos podem funcionar simultaneamente nos mesmos equipamentos e com base nisto a transição foi pensada para ser feita de forma gradual.

No projeto inicial do IPv6, uma vez que o protocolo estivesse pronto, sua implantação começaria a ser feita gradualmente na Internet, de forma que funcionasse simultaneamente ao IPv4. A isso chamamos de pilha dupla, ou dual stack. Quando o IPv6 estivesse implantado em todos os dispositivos, o IPv4 deixaria de ser realmente útil e poderia ser abandonado paulatinamente.

No período de implantação do IPv6 haveria necessidade de técnicas auxiliares de transição, inicialmente para interconectar ilhas IPv6 em uma Internet majoritariamente IPv4 e, depois de algum tempo, para fazer o contrário.

A transição feita desta forma seria muito simples de ser executada tecnicamente. Contudo, por diversas razões, não foi o que aconteceu. Atualmente o IPv6 ainda não está sendo amplamente utilizado na Internet e o esgotamento do IPv4 já se tornou uma realidade. Hoje existe a necessidade de se implantar o IPv6 numa Internet sempre crescente, onde os novos usuários ainda precisam de conectividade IPv4, mas não há mais endereços IPv4 livres para atendê-los. Assim, novas técnicas auxiliares foram e continuam sendo, desenvolvidas para essa nova realidade.

1. Cenários de coexistência de IPv6 e IPv4

Na transição do IPv4 para o IPv6 é necessária a coexistência e interoperabilidade entre ambos os protocolos e para isso é necessário o uso de tecnologias auxiliares, conhecidas como técnicas de transição. A necessidade de coexistência ocorre em diferentes cenários, cada qual com características e demandas singulares e uma técnica de transição isoladamente normalmente não é capaz de atender simultaneamente a todos. Assim, o primeiro passo para entender as técnicas de transição é entender os cenários existentes, as necessidades apresentadas e as dificuldades envolvidas.

A enumeração dos cenários a seguir é uma generalização e extensão da enumeração feita na RFC 6144. Contudo, enquanto esta RFC trata apenas de cenários utilizados com soluções de tradução, os mesmos são aqui usados para descrever também situações onde soluções de tunelamento podem ser aplicadas.

Cenário 1: Rede IPv6 para Internet IPv4 (R6-I4)

Devido a falta de entereços IPv4 ou outras limitações técnicas ou econômicas a rede cliente possui somente IPv6, mas necessita conectar-se a Internet IPv4.

Figura 1: cenário 1

Este cenário também pode ocorrer em greenfield networks, expressão em inglês usada para se referir a projetos totalmente novos, aos quais não se aplicam as restrições normalmente encontradas em tecnologias já em uso. Algumas empresas têm se decidido por criar redes somente IPv6 nesse caso, por motivos de simplicidade, facilidade de gerência e outros, mas necessitam ainda acessar servidores de clientes e fornecedores que estão na Internet IPv4.

Este cenário possui uma complexidade simples e é de fácil solução, sendo suportado por tanto por técnicas statless quanto stateful, que serão explicadas mais adiante.

Cenário 2: Internet IPv4 para Rede IPv6 (I4-R6)

Mesma rede existente no cenário 1, mas que necessita receber conexões da Internet IPv4, para o caso, por exemplo, de haver servidores IPv6 na rede, que devem atender solicitações de clientes na Internet IPv4.

Figura 2: cenário 2

A inversão no sentido de origem da comunicação torna este cenário muito mais complexo que o cenário 1, pois normalmente não se consegue fazer um mapeamento 1:1 de todos endereços IPv6 existentes na rede para endereços IPv4 válidos. Esse caso normalmente exige soluções stateful, mas pode ser também atendido por soluções stateless, desde que suportem conexões iniciadas via IPv4 para um subconjunto dos endereços IPv6 na rede.

Cenário 3: Internet IPv6 para Rede IPv4 (I6-R4)

Este é um típico cenário onde uma rede legada, onde não é possível fazer uma atualização para IPv6, necessita continuar em uso e responder requisições da Internet IPv6.

Figura 3: cenário 3

Para este cenário só cabem soluções stateful, já que a rede IPv4 deve comunicar-se com toda a Internet IPv6.

Cenário 4: Rede IPv4 para Internet IPv6 (R4-I6)

Este cenário só deve ser encontrado em estágios bem avançados da implementação do IPv6, quando a maior parte dos serviços na Internet já tiverem migrado para o novo protocolo. Técnicas de tradução na própria rede provavelmente não conseguirão solucionar esse problema.

Figura 4: cenário 4

Cenário 5: Rede IPv6 para Rede IPv4 (R6-R4)

Ambas as redes deste cenário estão na mesma organização e os endereços IPv6 e IPv4 podem ser públicos e válidos na Internet ou privados e válidos somente dentro da organização. Este cenário é bastante similar ao cenário 1 e os mesmos tipos de técnicas aplicadas a ele podem ser aplicadas a este.

Figura 5: cenário 5

Cenário 6: Rede IPv4 para Rede IPv6 (R4-R6)

De forma análoga ao cenário anterior, essa é uma situação semelhante ao cenário 2, mas com ambas as redes dentro da mesma organização. Os endereços IPv6 e IPv4 podem ser públicos e válidos na Internet ou privados e válidos somente dentro da organização. Os mesmos tipos de técnicas aplicadas ao cenário 2 podem ser aplicadas a este.

Figura 6: cenário 6

Cenário 7: Internet IPv6 para Internet IPv4 (I6-I4)

Este cenário, onde qualquer dispositivo na Internet IPv6 pode iniciar uma conexão com um dispositivo na Internet IPv4, necessita da técnica de transição perfeita, que também seria capaz de resolver todos os cenários anteriores, mas infelizmente ela não existe. A grande diferença na quantidade de endereços torna, até este momento, uma solução para este cenário técnicamente improvável.

Figura 7: cenário 7

Cenário 8: Internet IPv4 para Internet IPv6 (I4-I6)

Similar ao cenário 7 e com mesma dificuldade técnica de implementação.

Figura 8: cenário 8

Cenário 9: Rede IPv6 para Rede IPv6 bidirecional via Internet IPv4 (R6-I4-R6)

Este cenário apresenta o caso em que a comunicação entre duas redes com IPv6 necessita ser feita através da Internet IPv4 ou de Rede IPv4. A comunicação pode ser iniciada por ambas as Redes IPv6.

Figura 9: cenário 9

Cenário 10: Rede IPv4 para Rede IPv4 bidirecional via Internet IPv6 (R4-I6-R4)

Este cenário apresenta o caso em que a comunicação entre duas redes com IPv4 necessita ser transmitida através da Internet IPv6 ou de Rede IPv6. A comunicação pode ser iniciada por ambas as Redes IPv4.

Figura 10: cenário 10

No início da explicação de cada técnica de transição, no decorrer deste texto, haverá um quadro informativo para identificar quais destes cenários são suportados pela mesma. A seguinte legenda será utilizada na tabela: Rede IPv4 (R4), Rede IPv6 (R6), Internet IPv4 (I4), Internet IPv6 (I6).

2. Classificação das técnicas de transição

Como já foi visto, desde 1983 a estrutura da Internet é baseada no IPv4. Uma troca completa e imediata do protocolo seria inviável devido ao tamanho e à proporção desta rede. Por isso, o IPv6 foi projetado para ser implantado gradualmente.

O período de transição e de coexistência dos dois protocolos exigiu o desenvolvimento de técnicas auxiliares. O primeiro problema que elas procuravam resolver era como conectar redes IPv6 a outras redes IPv6 por meio de equipamentos ou de uma Internet que só suportassem IPv4. Surgiram então diversos tipos de túneis IPv6 sobre IPv4 para atender tal necessidade, usando diferentes técnicas, estabelecidos manualmente ou automaticamente. Foram criadas também técnicas para permitir que redes IPv6 e IPv4 interoperassem, por meio da tradução dos pacotes.

Mais recentemente, o problema principal a ser resolvido pela técnicas de transição passou a ser a implantação do IPv6 num ambiente em que o IPv4 não está mais disponível, mas ainda é necessário para os novos usuários da Internet. Foram, e continuam sendo, desenvolvidos então diversos tipos de túneis IPv4 sobre IPv6 para, aliados a técnicas de tradução, solucionar esse problema.

Pode-se, então, classificar as técnicas de transição segundo sua funcionalidade, em:

· Pilha dupla: consiste na convivência do IPv4 e do IPv6 nos mesmos equipamentos, de forma nativa, simultâneamente. Essa técnica é a técnica padrão escolhida para a transição para IPv6 na Internet e deve ser usada sempre que possível.

· Túneis: Permitem que diferentes redes IPv4 comuniquem-se através de uma rede IPv6, ou vice-versa.

· Tradução: Permitem que equipamentos usando IPv6 comuniquem-se com outros que usam IPv4, por meio da conversão dos pacotes.

Deve-se notar que tanto os túneis quanto as técnicas de tradução podem ser stateful ou stateless. Técnicas stateful são aquelas em que é necessário manter tabelas de estado com informações sobre os endereços ou pacotes para processá-los. Nas técnicas stateless não é necessário guardar informações, cada pacote é tratado de forma independente. De forma geral técnicas stateful são mais caras: gastam mais CPU e memória, por isso não escalam bem. Sempre que possível deve-se dar preferência a técnicas stateless.

Há casos em que é necessária a comunicação entre IPv4 e IPv6 para apenas um, ou poucos tipos de aplicações. Ou ainda, quando é usada uma técnica de tradução e ela funciona para quase todas as aplicações, mas falha para algumas poucas, nomeadamente aquelas que carregam endereços IP literais no protocolo, na camada de aplicação. Para esses casos podem ser usados gateways específicos, na camada de aplicação. São chamados de Application Level Gateways, ou ALGs.

Uma grande dificuldade no processo de implantação do IPv6 é o desenvolvimento de uma variedade enorme de técnicas de transição, o que dificulta a escolha do que efetivamente utilizar. A figura 11 ilustra essa variedade, nomeando diversos tipos de técnicas para túneis hoje padronizadas, ou em discussão na IETF, e organizando-as segundo sua funcionalidade e método de funcionamento. Nem todas serão abordadas neste texto.

De forma geral, os critérios que devem ser utilizados na escolha da técnica a ser utilizada, são:

· deve-se preferir técnicas que impliquem na utilização de IPv6 nativo pelos usuários finais, de forma que túneis IPv4 dentro de IPv6 devem ser preferidos em detrimento de túneis IPv6 sobre IPv4;

· deve-se preferir técnicas stateless em detrimento de técnicas statefull;

· deve-se evitar técnicas para prolongar o uso do protocolo IPv4, sem a adoção concomitante do IPv6;

· deve-se analisar a adequação da técnica à topologia da rede onde será aplicada e

· deve-se analisar a maturidade da técnica e as opções de implantação, como por exemplo suporte à mesma nos equipamentos de rede e em softwares.

Figura 11: classificação das técnicas de transição

Como uma terceira possibilidade de classificação, pode-se dividir as técnicas conforme seus casos de uso:

· Fornecer IPv6 e IPv4 para todos os dispositivos: pilha dupla.

· Oferecer conectividade IPv6 nativa em conjunto com conectividade IPv4 com compartilhamento e preservação de endereços: DS-Lite, DS-Lite com A+P, 4rd, NAT64, IVI e 464XLAT.

· Transportar IPv6 em uma rede MPLS IPv4: 6PE e 6VPE.

· Obter conectividade IPv6, quando o provedor Internet não a oferecer: tunnel broker e túneis estáticos 6over4 ou GRE.

· Oferecer conectividade IPv6 para os usuários sobre uma rede de transporte IPv4: 6rd (normalmente usado em provedores) e ISATAP (para redes internas).

· Mecanismos para compartilhar endereços IPv4, estendendo sua vida: A+P e NAT444.

3. Pilha Dupla: IPv6 e IPv4 em todos os dispositivos

Na atual fase de implantação do IPv6, não é aconselhável ter nós com suporte apenas a esta versão do protocolo IP, visto que muitos serviços e dispositivos na Internet ainda trabalham somente com IPv4. Como citado anteriormente, manter o IPv4 já existente funcionando de forma estável e implantar o IPv6 nativamente, para que coexistam nos mesmos equipamentos, é a forma básica escolhida para a transição na Internet. Esta técnica é conhecida como pilha dupla (Dual Stack ou DS) e deve ser usada sempre que possível.

A utilização deste método permite que dispositivos e roteadores estejam equipados com pilhas para ambos os protocolos, tendo a capacidade de enviar e receber os dois tipos de pacotes, IPv4 e IPv6. Com isso, um nó Pilha Dupla, ou nó IPv6/IPv4, se comportará como um nó IPv6 na comunicação com outro nó IPv6 e se comportará como um nó IPv4 na comunicação com outro nó IPv4.

Cada nó IPv6/IPv4 é configurado com ambos endereços, utilizando mecanismos IPv4 (ex. DHCP) para adquirir seu endereço IPv4 e mecanismos IPv6 (ex. configuração manual, autoconfiguração stateless e/ou DHCPv6) para adquirir seu endereço IPv6.

Este método de transição permita uma implantação gradual, com a configuração de pequenas seções do ambiente de rede de cada vez. Além disso, caso no futuro o IPv4 não seja mais usado, basta simplesmente desabilitar a pilha IPv4 em cada nó.

O funcionamento da pilha dupla está ilustrado na figura 12.

Figura 12: funcionamento da pilha dupla

Alguns aspectos referentes à infra-estrutura da rede devem ser considerados ao se implementar a técnica de pilha dupla: a estruturação do serviço de DNS e a configuração dos protocolos de roteamento e de firewalls.

Em relação ao DNS, é preciso configurar os novos endereços IPv6, usando registros do tipo AAAA (quad-A), que armazenam seus endereços. Para mais detalhes sobre o suporte do DNS ao IPv6, consulte a RFC 3596. Responder os endereços IPv6 (registros AAAA) quando disponíveis para um determinado nome de domínio é o comportamento padrão do servidor DNS, mesmo que ele opere apenas com IPv4. O protocolo por meio do qual é feita a consulta não interfere na resposta. Ao receber endereços IPv6 e IPv4 como resposta a uma consulta no DNS a aplicação decide qual protocolo usar. Normalmente a preferência é pelo protocolo IPv6 e, em caso de falha, tenta-se o IPv4. Mais recentemente têm sido experimentadas técnicas que implicam em tentativas simultâneas de conexão IPv6 e IPv4 e optam pela que for mais rápida (draft-ietf-v6ops-happy-eyeballs-07).
Em uma rede com pilha dupla, a configuração do roteamento IPv6 normalmente é independente da configuração do roteamento IPv4. Isto implica no fato de que, se antes de implementar-se o IPv6 a rede utilizava apenas o protocolo de roteamento interno OSPFv2 (com suporte apenas ao IPv4), será necessário migrar para um protocolo de roteamento que suporte tanto IPv6 quanto IPv4 (como ISIS por exemplo) ou forçar a execução do OSPFv3 paralelamente ao OSPFv2.

A forma como é feita a filtragem dos pacotes que trafegam na rede pode depender da plataforma que se estiver utilizando. Em um ambiente Linux, por exemplo, os filtros de pacotes são totalmente independentes uns dos outros, de modo que o iptables filtra apenas pacotes IPv4 e o ip6tables apenas IPv6, não compartilhando nenhuma configuração. No FreeBSD, as regras são aplicadas a ambos os protocolos no mesmo arquivo de configuração. Entretanto a regra pode ser aplicada simultâneamente aos dois protocolos ou a somente um. Para aplicar a somente um deles basta utilizar inet ou inet6 dependendo do protocolo à qual as regras devem ser aplicadas. De uma forma ou de outra, novas regras terão de ser configuradas no firewall ao implantar-se o IPv6.

É importante reforçar que configurações independentes para IPv4 e IPv6 são necessárias para diversos aspectos da rede, entre eles:

· Informações nos servidores DNS autoritativos;

· Protocolos de roteamento;

· Firewalls;

· Gerenciamento das redes.

Utilizar pilha dupla pode não ser possível em todas as ocasiões. Por exemplo, quando não há mais IPv4 disponíveis e o provedor precisa atender a usuários novos com IPv6 e IPv4. Para redes corporativas que já utilizam NAT isso não é um impendimento: o IPv6 nativo pode ser utilizado em conjunto com o IPv4 compartilhado. Outra situação que dificulta a implantação do IPv6 usando pilha dupla é a existência de equipamentos que não o suportam e que não podem ser facilmente substituídos. Para contornar essas situações existem diversas técnicas disponíveis, algumas das quais serão abordadas nas próximas sessões.

4. Túneis 6over4 (IPv6-over-IPv4)

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

Quando a utilização de pilha dupla não é possível, umas das alternativas a ser considerada é a utilização de túneis. As técnicas de tunelamento fazem o encapsulamento de pacotes IPv6 em pacotes IPv4. Este encapsulamento é conhecido como 6in4 ou IPv6-in-IPv4 (RFC 4213). Ele consiste em colocar o pacote IPv6 dentro de um pacote IPv4, adequar os endereços de origem e destino para o IPv4 e colocar no cabeçalho o tipo 41 (29 em hexadecimal). Esse tipo de encapsulamento é conhecido por 6in4, ou como “protocolo 41”. Quando o destino receber o pacote com tipo 41 ele irá remover o cabeçalho IPv4 e tratar o pacote como IPv6. A figura 13 ilustra esse comportamento.

Também é possível, de forma análoga, encapsular pacotes IPv4 em pacotes IPv6, técnica conhecida como 4in6. Algumas das técnicas de transição estudadas mais à frente fazem isso.

Figura 13: funcionamento 6in4

Uma das formas de utilizar-se túneis é criando-os manualmente. A técnica 6over4 (RFC 4213) utiliza um túnel manual estabelecido entre dois nós IPv4 para enviar o tráfego IPv6. Todo o tráfego IPv6 a ser enviado é encapsulado em IPv4 usando 6in4, explicado anteriormente. A configuração manual consiste em definir quais serão os IPs v4 de origem e destino que serão utilizados em cada ponta do túnel. Ao ser recebido pelo nó destino, o pacote IPv6 é desencapsulado e tratado adequadamente.

Esse tipo de túnel pode ser utilizado para contornar um equipamento ou enlace sem suporte a IPv6 numa rede, ou para criar túneis estáticos entre duas redes IPv6 através da Internet IPv4.

É importante entender a diferença entre 6over4 e 6in4. O túnel 6over4 é um túnel estabelecido manualmente que tem o objetivo de permitir conexão IPv6 entre dois nós de rede conectados por uma rede via IPv4. Ele usa o encapsulamento 6in4. Já o encapsulamento 6in4, com a utilização do tipo 41, pode ser utilizado também em outras técnicas de transição que transportam pacotes IPv6 em redes IPv4, como poderá ser observado ao longo deste texto.

Criar um túnel 6over4 é bastante fácil. A seguir serão mostrados exemplos de como fazer esta implementação no Linux e com roteadores Cisco. A topologia da implementação em Linux é:
Descrição: img14

Figura 14: túnel manual 6over4 entre dois dispositivos

Os computadores Host A e Host B são computadores Linux e os roteadores simplesmente representam uma rede somente IPv4 ou a Internet IPv4. Os computadores devem ser configurados com os seguintes passos:

No Host A, basta digitar os comandos:

ip tunnel add toHostB mode sit ttl 64 remote 192.0.2.130 local 192.0.2.2ip link set dev toHostB upip -6 route add 2001:db8::b0ca dev toHostB

De forma análoga, no Host B:

ip tunnel add toHostA mode sit ttl 64 remote 192.0.2.2 local 192.0.2.130 ip link set dev toHostA up
ip -6 route add 2001:db8::ba1a dev toHostA

Para verificar o correto funcionamento pode-se utilizar o comando ping6 antes e depois de fazer as configurações. Será possível notar que as duas máquinas passaram a comunicar-se via IPv6.

Para o exemplo de configuração em roteadores Cisco de túneis 6over4 a topologia será:
Descrição: img15

Figura 15: túnel manual 6over4 entre dois roteadores

Para a configuração do túnel somente é necessária a configuração do Roteador A e do Roteador B.

No Roteador A:

configure terminal
interface Tunnel10
ipv6 address 2001:db8:100::1/64
tunnel source 198.51.100.5
tunnel destination 203.0.113.198
tunnel mode ipv6ip
end

Ainda no Roteador A, é necessário ativar o roteamento IPv6 e criar uma rota para a rede do Roteador B, apontando para o Túnel 6over4:

ipv6 unicast-routing
ipv6 route 2001:db8:20::/64 2001:db8:100::2

De forma análoga, no Roteador B:

configure terminalinterface Tunnel20ipv6 address 2001:db8:100::2/64
tunnel source 203.0.113.198
tunnel destination 198.51.100.5
tunnel mode ipv6ip
endipv6 unicast-routing
ipv6 route 2001:db8:10::/64 2001:db8:100::1

Mais uma vez, é possível testar a configuração utilizando o ping para IPv6.

5. Túneis GRE

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

Outra opção de túnel estático para o tranporte de IPv6 em redes IPv4 é o GRE (Generic Routing Encapsulation – RFC 2784). Ele é um túnel estático entre dois nós originalmente desenvolvido pela Cisco com a finalidade de encapsular vários tipos diferentes de protocolos, como por exemplo IPv6 e ISIS (a lista completa dos protocolos suportados pode ser encontrada emhttp://www.iana.org/assignments/ethernet-numbers). Este tipo de encapsulamento é suportado na maioria do sistemas operacionais e roteadores e possibilita a criação de um link ponto a ponto. Assim como o 6over4 sua configuração é manual, de modo que pode gerar um esforço na sua manutenção e gerenciamento proporcional à quantidade de túneis.

O pacote com cabeçalho é explicado na figura a seguir:

Figura 16: pacote com cabeçalho GRE

O funcionamento deste tipo de túnel é muito simples: consiste em pegar os pacotes originais, adicionar o cabeçalho GRE e o cabeçalho IPv4 e enviar ao IP de destino. Quando o pacote encapsulado chegar na outra ponta do túnel (IP de destino) remove-se dele os cabeçalhos IPv4 e GRE, restando apenas o pacote original, que é encaminhado normalmente ao destinatário.

A configuração dos túneis GRE é muito semelhante àquela feita para o 6over4. No exemplo dado para roteadores Cisco, no item 4, basta trocar:

tunnel mode ipv6ip

por

tunnel mode gre

6. Tunnel Broker

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

Descrita na RFC 3053, essa técnica permite que dispositivos isolados, ou toda uma rede IPv4, obtenham conectividade IPv6 por meio do estabelecimento de um túnel com um provedor, tornando-se, na prática, dispositivos, ou uma rede, pilha dupla.

Seu funcionamento é bastante simples: primeiramente é necessário realizar um cadastro, normalmente via Web, em um provedor que ofereça esse serviço, chamado, neste contexto, de Tunnel Broker. O provedor realizará de forma automática, ou semi automática, a configuração do seu lado do túnel e permitirá o download de instruções, ou de um software ou script de configuração, para configurar o lado do usuário. Os Tunnel Brokers normalmente oferecem blocos fixos IPv6 que variam de /64 a /48.

Dentre as opções existentes, recomenda-se:

· http://tunnelbroker.net/ - serviço oferecido pela Hurricane Electric, que provê túneis para usuários domésticos ou corporativos, inclusive com a possibilidade de se fechar sessões BGP para provimento de trânsito IPv6 via túnel.

· http://www.sixxs.net/main/ - serviço oferecido de forma colaborativa por um grande número de organizações. Não é possível fechar sessões BGP, mas é possível obter redes fixas de tamanho /48 roteadas através do túnel. A Algar Telecom/CTBC é responsável por um dos POPs em que são configurados os túneis, no Brasil, de forma que para usuários em redes brasileiras os túneis funcionam com qualidade e velocidade próximas às de conexões nativas.

Os Tunnel Brokers podem usar tecnologias diversas para prover os túneis. Podem usar, por exemplo, túneis 6in4, encapsulamento em UDP, o protocolo AYIYA, que significa Anything in Anything (draft-massar-v6ops-ayiya-02), ou TSP (Tunnel Setup Protocol), definido na RFC 5572.

A utilização de Tunnel Brokers é recomendada para usuários domésticos e corporativos que querem testar o IPv6, ou começar um processo de implantação em suas redes, mas cujos provedores de acesso ainda não oferecem suporte ao protocolo. Muitos Sistemas Autônomos brasileiros têm utilizado com sucesso túneis com a Hurricane Electric para anunciar seus blocos em caráter de teste e muitas empresas e usuários domésticos têm utilizado túneis SixXS para familiarizar-se com o IPv6.

A implantação de um serviço de Tunnel Broker em um provedor Internet não é trivial, pois não há softwares abertos disponíveis para a funcionalidade de Servidor Broker.

As figuras abaixo mostram a topologia lógica e física do Tunnel Broker.

1 – Cliente pilha dupla solicita túnel (pode ser solicitada autenticação) via IPv4
2 – Broker cadastra usuário no Servidor de túnel
3 – Broker informa cliente parametros para criação do túnel
4 – Túnel estabelecido

Figura 17: Topologia lógica do Tunnel Broker

Figura 18: Topologia física do Tunnel Broker

O exemplo de implementação de Tunnel Broker será baseado no OpenWRT (openwrt.org). Ele é um firmware opensource para roteadores sem fio SOHO (small office / home office). Como provedor do túnel será utilizada a solução da Hurricane Eletric (tunnelbroker.com). Abaixo o passo a passo da instalação:

1. Criar um usuário em tunnelbroker.com e solicitar um túnel
2. Instalar os pacotes necessários no OpenWRT:

opkg install ip ip6tables kmod-sit kmod-iptunnel6 radvd

3. Criar o arquivo /etc/hotplug.d/iface/15-ipv6 com o seguinte código (ele considera que a conexão com o provedor utiliza PPP, se for outro tipo de conexão o código necessita pequenas alterações):

. /etc/functions.sh
NAME=ipv6
COMMAND=/usr/sbin/ip

[ "$ACTION" = "ifup" -a "$INTERFACE" = "wan" -a "$DEVICE" = "ppp0" ] && {

[ -x $COMMAND ] && {

# setup tunnel

logger "HE-IPv6: starting tunnel..."

IPADDR=$(ip -4 addr show dev $DEVICE |

awk '/inet / {print $2}' |
cut -d/ -f1)
username="abcdef1234567890abcdef1234567890" # MD5 of your username
password="abcdef1234567890abcdef1234567890" # MD5 of your password
tunnelid="69999" # global tunnel-ID

# update tunnel to use dynamic ipv4
wget -q -O /dev/null "http://ipv4.tunnelbroker.net/ipv4_end.php?ipv4b=
$IPADDR&pass=$password&user_id=$username&tunnel_id=$tunnelid"

SERVER_IPv4_ENDPOINT=216.66.80.30 # change this IP to your option
CLIENT_IPv6_ENDPOINT=2001:470:1f0a:9999::2/64 # change this, too

# setup tunnel
ip tunnel add he-ipv6 mode sit remote $SERVER_IPv4_ENDPOINT local $IPADDR ttl 255
ip link set he-ipv6 up
ip addr add $CLIENT_IPv6_ENDPOINT dev he-ipv6
ip route add ::/0 dev he-ipv6
} &
}
[ "$ACTION" = "ifdown" -a "$INTERFACE" = "wan" -a "$DEVICE" = "ppp0" ] && {
[ -x $COMMAND ] && {
# destroy tunnel

logger "HE-IPv6: destroying tunnel..."
ip route del ::/0 dev he-ipv6
ip tunnel del he-ipv6
} &
}

# You got a routed /64

4. Adicionar um IP para a interface do túnel:

uci set network.lan.ip6addr=2001:470:1f0b:9999::1/64

uci commit

5. Configurar o firewall do OpenWRT para aceitar pacotes com protocolo 41 vindos da interface WAN
6. Configurar o anúncio da rede IPv6 na LAN, editando o arquivo /etc/config/radvd :

config interface

option interface ’lan’

option AdvSendAdvert 1

option AdvManagedFlag 0

option AdvOtherConfigFlag 0

option ignore 0

config prefix

option interface ’lan’

# If not specified, a non-link-local prefix of the interface is used

option prefix ’2001:470:1f0b:9999::/64′

option AdvOnLink 1

option AdvAutonomous 1

option AdvRouterAddr 0

option ignore 0

config rdnss

option interface ’lan’

# If not specified, the link-local address of the interface is used

option addr ’2001:470:1f0b:9999::/64′

option ignore 1

Alterar o endereço “:9999” para a rota que você utilizou. Salvar o arquivo e executar os comandos para que as alterações sejam aplicadas:

/etc/init.d/radvd enable

/etc/init.d/radvd start

7. A configuração está completa. Reiniciar o roteador e testar o túnel. Pode-se executar o ping6 diretamente no roteador e funcionando corretamente executá-lo a partir de um computador na LAN:

ping6 ipv6.google.com

Em caso de dúvidas, os tutoriais da Hurricane Eletric ou do OpenWRT podem ser consultados em:

http://www.tunnelbroker.net/forums/index.php?topic=1016.0

http://wiki.openwrt.org/doc/uci/network#dynamic.ipv6-in-ipv4.tunnel.he.net.only

Outro exemplo de confuguração é a utilização de Tunnel Broker no Windows. É possível utilizá-lo em diversas versões do WIndows (2000, XP, 2008, Vista e 7) desde que o suporte IPv6 seja instalado nas versões que não o suportam nativamente. A configuração deve ser feita através do console usando um usuário com permissões administrativas. As configurações para estas versões do Windows são:

Explicação das variáveis usadas:

$ipv4a = IPv4 do servidor do túnel

$ipv4b = IPv4 do usuário do túnel

$ipv6a = rede /64 alocada ao lado do servidor do túnel

$ipv6b = rede /64 alocada ao lado do usuário do túnel

Windows 2000/XP:

ipv6 install

ipv6 rtu ::/0 2/::$ipv4a pub

ipv6 adu 2/$ipv6b

Windows 2008/Vista/7

netsh interface ipv6 add v6v4tunnel interface=IP6Tunnel $ipv4b $ipv4a

netsh interface ipv6 add address IP6Tunnel $ipv6b

netsh interface ipv6 add route ::/0 IP6Tunnel $ipv6a

7. Dual Stack Lite (DS-Lite)

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

Serão analisadas agora algumas técnicas bastante pertinentes ao momento atual da transição para o IPv6, num cenário em que não há mais IPv4 disponíveis, mas a base de usuários do provedor continua a crescer e ainda há muitos serviços exclusivamente disponíveis em IPv4 na Internet. Desta forma, o provedor não pode oferecer exclusivamente conectividade IPv6 ao usuário final, sendo forçado a oferecer também conectividade IPv4, mas com IPs de alguma forma compartilhados.

A primeira técnica a ser analisada será o Dual Stack Lite (Pilha dupla simplificada), padronizada na RFC 6333. Ela pode ser aplicada em situações em que o provedor já oferece IPv6 nativo para seus usuários. Sua implementação necessita de um equipamento denominado AFTR (Address Family Transition Router), que implementa um CGN (Carrier Grade NAT), que é um NAT de grande porte, na rede do provedor. Entre o AFTR e o CPE do usuário utiliza-se um túnel IPv4 sobre IPv6 para transportar o tráfego IPv4. No contexto do DS-Lite, o CPE do usuário é chamado de B4, abreviação para DS-Lite Basic Bridging BroadBand. Nas extremidades desses túneis são usados endereços da faixa 192.0.0.0/29, especialmente reservada para este fim. Para o CPE do usuário e os demais equipamentos da rede do usuário são utilizados IPs da RFC 1918 e não há problema se diferentes usuários utilizarem faixas de IPs repetidas, dado que o AFTR identifica os diferentes túneis com base no IPv6 de origem dos pacotes encapsulados. Na CPE do usuário deve existir um DHCP v4 para a distribuição dos endereços na rede interna. Deve existir também um proxy DNS, que permita consultas via IPv4, mas faça essas consultas ao DNS recursivo do provedor via IPv6, evitando traduções desnecessárias no AFTR.

É importante frisar alguns pontos:

· O AFTR usa CGN, mas não força o usuário a utilizar duplo NAT. Ou seja, AFTR realiza a função de NAT, de forma concentrada, para cada um dos dispositivos de cada usuário.

· O DS-Lite utiliza endereços privados na faixa 192.0.0.0/29 para as extremidades dos túneis v4 sobre v6, evitando a utilização desnecessária de endereços IPv4 na infraestrutura do provedor.

A figura 19 mostra um exemplo de topologia.

Figura 19: Exemplo topologia DS-Lite

Uma alternativa para implantar o DS-Lite é a utilização do software AFTR desenvolvido pelo ISC (Internet Systems Consortium), inicialmente por solicitação e com financiamento da Comcast, um grande provedor que opera com cabo nos Estados Unidos. O software está disponível no URLhttp://www.isc.org/software/aftr e pode ser utilizado em servidores GNU/Linux no provedor, permitindo uma implementação de baixo custo, robusta e escalável. Para o B4 (CPE) podem ser utilizados também dispositivos rodando Linux. Em especial, é possível utilizar roteadores Linksys WRT54GL e outros compatíveis com o firmware OpenWRT disponível no URL:

http://www.kangaroo.comcast.net/wiki/doku.php?id=wrt54gl:wrt54gl.

A configuração desta topologia é bastante simples. Para configurar o AFTR, basta criar um arquivo chamado aftr-script, contendo:

aftr_start() {

set -x

ip link set tun0 up

ip addr add 192.0.0.1 peer 192.0.0.2 dev tun0

ip route add 203.0.113.1/32 dev tun0

ip -6 addr add fe80::1 dev tun0

ip -6 route add 2001:db8:c::1/64 dev tun0

arp -i eth0 -s 203.0.113.131 0a:0b:0c:0d:0e:f0 pub

}

aftr_stop() {

set -x

ip link set tun0 down

}

case “$1” in

start)

aftr_start

;;

stop)

aftr_stop

;;

*)

echo “Usage: $0 start|stop””

exit 1

;;

esac

exit 0

E um arquivo de configuração chamado aftr.conf, contendo:

default tunnel mss on

defmtu 1450

address endpoint 2001:db8:c::1

address icmp 203.0.113.1

pool 203.0.113.1

acl6 ::0/0

E então iniciar o serviço.

Para o B4 (CPE), basta criar o túnel IPv4 sobre IPv6:

modprobe ip6_tunnel

ip -6 tunnel add dsltun mode ipip6 remote 2001:db8:c::1 local 2001:db8:0:b::1 dev eth1

ip addr add 192.0.0.2 peer 192.0.0.1 dev dsltun

ip link set dev dsltun up

ip route add default dev dsltun

Além disso, deve-se configurar o DHCPv4 e o proxy DNS no B4.

Esse exemplo de configuração usa apenas um endereço para o pool de NAT, mas poderiam ser utilizados mais. Note que o endereço IPv4 da interface física do servidor AFTR não está na mesma rede dos endereços usados no pool. O endereço IPv6 da extremidade AFTR do túnel não é o endereço físico da interface, mas outro, numa rede diferente. Os pacotes direcionados para os endereços do Pool IPv4 e para o endereço IPv6 da extremidade do túnel são roteados para a interface de túnel e tratados pelo software AFTR. Por fim, é importante notar que os mesmos endereços 192.0.0.1 e 192.0.0.2 são usados para múltiplos clientes e que a detecção de novos túneis de clientes é feita automaticamente pelo AFTR, com base no endereço IPv6 de origem dos mesmos.

Uma variação desta técnica, que tenta resolver o mesmo problema, é a combinação do DS Lite com o Address Plus Port (A+P) e é conhecida como DS Lite A+P. O A+P será apresentado com mais detalhes no item 17 deste texto. O funcionamento do DS Lite A+P é similar ao DS Lite, mas ao invés de ser um endereço IPv4 privado, o CPE do usuário recebe um endereço IPv4 público. As portas disponíveis para utilização, contudo, são limitadas, pois este IP público é compartilhado com outros nós. O CPE deve então realizar a função de tradução de endereços (NAT), oferecendo IPs privados (RFC 1918) para os demais nós na rede, mas obedecendo à restrição das portas imposta pelo A+P na tradução.

Com a utilização do DS-Lite com A+P, a escalabilidade é melhor, dado que o NAT é feito de forma distribuida, nos CPEs. O usuário pode também realizar o mapeamento de portas no NAT e receber conexões entrantes, numa situação muito próxima a que existiria sem o compartilhamento de endereços.

O DS Lite com A+P é ilustrado na figura a^[a] seguir. Na figura, o CPE recebe o endereço IPv4 restrito das portas 1024 a 2047, à guisa de exemplo, mas tanto as portas disponíveis, quanto a quantidade das mesmas, poderiam ser outras.

Figura 20: Exemplo topologia DS-Lite com A+P
Deve-se notar que o DS-Lite e o DS-Lite com A+P usam IPv4 sobre IPv6, mas utilizam-se de técnicas stateful para o compartilhamento dos endereços IPv4.

8. IVI, dIVI e dIVI-pd

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	Sim	Sim	Não	Não	Não	Não

No item anterior foi apresentado o DS-Lite, que era útil para utilização no provedor, num cenário em que não há mais endereços IPv4 disponíveis, mas onde sua base de usuários continua a crescer. Desta forma, o provedor não pode oferecer exclusivamente conectividade IPv6 ao usuário final, sendo forçado a oferecer também conectividade IPv4, mas com IPs de alguma forma compartilhados.

O dIVI (draft-xli-behave-divi-04) e o dIVI-pd (draft-xli-behave-divi-pd-01) são alternativas de solução para o mesmo problema, mas têm a vantagem de usar técnicas stateless baseadas numa dupla tradução de pacotes, diferentemente do DS-Lite, que é stateful e baseado em tunelamento. Estes métodos de tradução stateless são capazes de manter a transparência fim a fim do endereço IP, não necessitando de técnicas auxiliares como DNS64 (tradução de DNS) ou ALG (gateways para aplicações específicas). Ambos os protocolos usam compartilhamento de IPs v4 com restrição de portas, de forma análoga ao A+P, discutido no item 17.

Ambas as soluções são extensões do IVI (RFC6219), cujo nome vem da concatenação dos numerais romanos IV (4) e VI (6). O IVI é um mecanismo de tradução stateless 1:1, desenvolvido por pesquisadores da CERNET2, a rede acadêmica chinesa, que é somente IPv6. A China optou por criar uma rede acadêmica IPv6 pura, totalmente nova, no lugar de implantar o IPv6 em pilha dupla na rede já existente. Essa estratégia pode parecer estranha atualmente, mas permitiu o desenvolvimento da industria nacional de equipamentos de rede e, em conjunto com incentivos econômicos para uso da nova rede, alavancou a implantação do IPv6 nas universidades e o desenvolvimento de diversas aplicações. Em muitas universidades chinesas, na atualidade, o tráfego IPv6 é maior do que o IPv4

O IVI foi criado inicialmente para permitir que servidores IPv6, ligados à CERNET2, pudessem comunicar-se com a Internet IPv4. Para isso um endereço IPv4 é atribuído virtualmente ao dispositivo, utilizando-se um mecanismo de tradução de pacotes stateless.

As três soluções, IVI, dIVI e dIVI-pd são experimentais. Existem relatos de implantação e teste realizados na CERNET/CERNET2 e pela China Telecom. Para o IVI há código disponível publicamente, na forma de um patch para o kernel do Linux, para o dIVI e o dIVI-pd não há implementações públicas disponíveis.

Em primeiro lugar, será apresentado o funcionamento do IVI.

Pode-se entender o conceito do funcionamento do IVI imaginando-se que ele cria um nó IPv6 espelho para o IPv4 e um nó IPv4 espelho para o IPv6, sendo que um nó espelho é um endereço que simula a presença do dispositivo na rede, mas que na verdade encaminha os pacotes enviados a ele para o dispositivo real através da tradução stateless. O servidor ou usuário IPv6 nativo na rede atendida pelo IVI, embora não tenha um endereço IPv4 atribuído a si, é visto por um nó IPv4 na Internet por meio de seu “endereço espelho” e, de forma análoga, enxerga um nó IPv4 qualquer na Internet por meio de seu “endereço IPv6 espelho”.

A figura abaixo demonstra o conceito.

Figura 21: Explicação conceitual do IVI

O provedor, para implantar o IVI, escolhe um subconjunto de seu bloco IPv4, que será usado para formar endereços IPv6, a fim de atender os servidores, ou usuários somente IPv6, que se comunicarão com a Internet IPv4 por meio do IVI. Os endereços são mapeados conforme a figura a seguir.

Figura 22: Mapeamento de endereços IPv6 em IPv4 e vice-versa

Por exemplo, um provedor cujo bloco IPv6 é 2001:db8::/32 e cujo bloco IPv4 é 192.61.100.0/24 pode escolher o prefixo IPv6 2001:db8:ff00::/40 e o bloco IPv4 192.51.100.0/26 para formar os endereços IVI. Os endereços IPv4 são mapeados para IPv6, então, da seguinte forma:

192.51.100.1 – 2001:db8:ffc0:3364:0100::0192.51.100.2 – 2001:db8:ffc0:3364:0200::0(…)

192.51.100.62 – 2001:db8:ffc0:3364:3e00::0

Na implementação feita pela CERNET o prefixo é um /40 e os bits de 32 a 39 são todos 1, para identificar o endereço IVI. Os bits 40 a 71 abrigam o endereço válido IPv4, representado no formato hexadecimal. Nesse formato, um IPv4 /24 é mapeado para um IPv6 /64 e um IPv4 /32 é mapeado para um IPv6 /72, mas o sufixo usado é sempre composto por zeros, de forma que apenas um endereço IPv6 é, na prática, mapeado para um endereço IPv4.

Note que o IVI não é uma solução para o esgotamento do IPv4. Para seu funcionamento é necessário separar um conjunto de endereços IPv4 válidos, do bloco disponível no provedor, e mapeá-lo para um conjunto de endereços IPv6 globais. A tradução no IVI é feita de forma stateless, o que é simples de implementar e escala bem. Note também que o IVI precisa funcionar em conjunto com o DNS64, caso seja necessário resolver os nomes de dispositivos IPv4. Veja ainda que os métodos de tradução como IVI e NAT64 não funcionam com aplicações que carregam os endereços IP na camada de aplicação, sendo necessária a utilização de ALGs (Application Layer Gateways) nesses casos. Por fim, é importante observar que o IVI oferece conectividade fim a fim, seja IPv4 ou IPv6, para os dispositivos atendidos.

Figura 23: Tradução de endereços no IVI

As regras aplicadas na tradução do cabeçalho dos pacotes estão especificadas na RFC 6145 e são mostradas a seguir:

Figura 24: Conversão de cabeçalhos IPv4 para IPv6

Figura 25: Conversão de cabeçalhos IPv6 para IPv4

O caso de aplicação mais comum para o IVI é oferecer visibilidade IPv4 para servidores somente IPv6 dentro de uma determinada rede, mas ele poderia ser utilizado também para usuários, com a mesma finalidade, desde que haja uma quantidade suficiente de endereços IPv4 disponíveis. Os dispositivos que utilizarem o IVI devem usar endereçamento manual ou DHCPv6, pois o endereço precisa seguir um padrão específico que não pode ser obtido pela autoconficuração IPv6.

O IVI ainda não está largamente implementado e atualmente a única maneira de testá-lo é através do Linux. Para usar o IVI é necessário aplicar um patch ao kernel do Linux, este patch está disponível em: http://www.ivi2.org/IVI/.

Após aplicar o patch é necessário habilitar a opção IVI e o protocolo IPv6 deve ser adicionado no modo “built in” e não como módulo. No menuconfig do kernel estas opções estão em:

Networking →
Networking Options →
[*] IVI(test only)
<*> The IPv6 protocol

Deve-se então compilar e instalar o kernel, e executar o script de configuração abaixo, fazendo as modificações de endereço necessárias para a rede onde a técnica será aplicada:

#!/bin/bash
# habilite o redirecionamento (forwarding)
echo 1 > /proc/sys/net/ipv6/conf/all/forwarding
echo 1 > /proc/sys/net/ipv4/conf/all/forwarding

# configure rota para IVI6 = 2001:0db8:ffc0:3364::/70,
# IVI4 = 192.51.100.0/26

# configure rota IPv6, sempre configurar rotas explicitas para as

# redes mapeadas, nao usar rotas default

route add -A inet6 2001:0db8:ffc0:3364::/70 gw 2001:db8::1 dev eth0

# configure mapeamento para source-PF = 2001:db8::/48
# configure mapeamento para destination-PF = 2001:db8::/48

# para cada mapeamento, um pseudo-endereço único (10.0.0.x/8) deve ser configurado
ip addr add 10.0.0.1/8 dev eth0

# Mapeamento IPv4-to-IPv6, múltiplos mapeamentos podem ser feitos via múltiplos

# comandos:

# mroute IVI4-network IVI4-mask pseudo-address interface source-PF destination-PF
mroute 192.51.100.0 255.255.255.192 10.0.0.1 eth0 2001:db8:: 2001:db8::

# Mapeamento IPv6-to-IPv4
# mroute6 destination-PF destination-PF-pref-len
mroute6 2001:db8:ff00:: 40

Uma vez apresentado o IVI, pode-se entender o funcionamento do dIVI e do dIVI-pd. Ambas as técnicas utilizam tradução dupla e compartilhamento de endereços IPv4, com restrição de portas. Dessa forma, os nós atendidos por elas usam pilha dupla, tendo IPv6 nativo para a comunicação com a Internet IPv6 e um IPv4 compartilhado. Com o dIVI e o dIVI-pd a comunicação fim a fim é possível, tanto com o uso de IPv4, como com o uso de IPv6, guardando-se a restrição de que apenas um subconjunto do total de portas está disponível para um determinado dispositivo no IPv4. Não é necessário o uso de NAT64 e nem de ALG.

A figura 26 representa tanto o funcionamento do dIVI, quanto do dIVI-pd.

Figura 26: Topologia da rede com a utilização do dIVI e dIVI-pd

A seguir o funcionamento do dIVI será apresentado com maior nível de detalhamento.

No dIVI os endereços IPv4 são mapeados em IPv6 usando um formato definido no draft-bcx-behave-address-fmt-extension, que é uma extensão da RFC 6052. Nesse formato, que pode usar prefixos IPv6 com diferentes tamanhos, é possível carregar o endereço IPv4 que está sendo compartilhado e também informações que identificam quais são as faixas de portas que podem ser utilizadas pelo nó: o PSID que é uma espécie de identificador da CPE e o Q, que indica qual a taxa de compartilhamento de endereços. Com essas informações um algoritmo muito simples na CPE identifica quais portas podem e quais não podem ser usadas. De forma análoga, o tradutor IVI N:1 na rede do provedor traduz o IPv4 de destino para o endereço IPv6 correspondente, baseando-se tanto no endereço, quanto na porta. Os bits de 64 a 71, representados por “u”, devem possuir valor zero. Eles são reservados para compatibilidade com o formato de identificação de dispositivo na arquitetura de endereçamento IPv6, de acordo com a RFC 4291.

Figura 27: Endereçamento IPv6 traduzido do IPv4 pelo dIVI

Na CPE pode haver dois tipos de tradução. Pode ser feita uma tradução totalmente stateless, mas, nesse caso, o nó deve conhecer a priori a restrição das portas e enviar os pacotes já obedecendo a isso. Outra possibilidade é a tradução na CPE ser parcialmente statefull, de forma que o nó não precise obedecer a qualquer restrição quanto à porta de origem. Nesse segundo caso, a CPE deve fazer a tradução das portas e manter o estado dessa tradução.

Note-se que no dIVI apenas um endereço IPv4 e um endereço IPv6 são atribuídos ao dispositivo. Um caso de uso esperado para essa técnica é o uso para dispositivos móveis, em redes 3G ou 4G. O sistema operacional do dispositivo poderia suportar as funções da CPE dIVI, ou seja, tradução 1:1 de IPv4 para IPv6 e mapeamento de portas, de forma que, funcionando como um nó somente IPv6 na realidade, ainda assim pudesse oferecer uma API pilha dupla para as aplicações.

Uma vez detalhado o funcionamento do dIVI, pode-se agora apresentar com mais detalhes o funcionamento do dIVI-pd.

O dIVI e o dIVI-pd são, de fato, muito parecidos. O dIVI-pd permite que seja designado um prefixo IPv6 para o dispositivo, no lugar de um único endereço. Dessa forma é possível utilizar a autoconfiguração stateless, ou ainda endereçar toda uma rede com diversos nós. É importante observar que apenas um endereço IPv4 continua sendo atribuído para cada CPE no dIVI-pd, de forma que se for necessário atribuir endereços IPv4 para mais de um nó, a CPE deverá fazê-lo utilizando NAT44 e endereços privados, da RFC 1918.

O dIVI-pd também utiliza os endereços no formato definido pela RFC 6052, com o prefixo de comprimento /64 e dois tipos de extensões, o CPE index, como parte do prefixo e o sufixo no mesmo formato utilizado pelo dIVI.

Figura 28: Endereçamento IPv6 traduzido do IPv4 pelo dIVI-pd

Note que para os usuários é possível atribuir prefixos /64, ou mais curtos, como /60 ou /56. Isso determina o valor de m (preenchimento com zeros). Note ainda que o fato do formato de sufixo ser o mesmo utilizado pelo dIVI permite a construção de CPEs compatíveis com as duas técnicas.

O dIVI e o dIVI-pd são realmente ótimas soluções, tendo características praticamente ideais para uso por provedores de acesso, por isso seu desenvolvimento e padronização devem ser acompanhados com muita atenção:

· operam com base em redes somente IPv6, que é para onde caminha a Internet;

· utilizam 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;

· não necessitam de ALG ou DNS64;

· quando necessário o uso de técnicas statefull, para tradução de portas, 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;

· a tradução implementada no provedor, de IPv6 para IPv4, N:1, pode ser usada de forma isolada, em conjunto com DNS64 e eventualmente ALGs, para clientes soemte IPv6; CPEs com suporte à tradução no sentido inverso poderiam ser implementados apenas para os clientes para os quais esse método não for suficiente e que realmente necessitarem de endereços IPv4 nos dispositivos.

9. NAT64 e DNS64

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

Uma outra técnica de tradução aplicável em situações similares as do IVI, dIVI e dIVI-pd, ou seja, para nós somente IPv6 acessarem a Internet IPv4 é o NAT64 (RFC 6146). O NAT64 é uma técnica stateful de tradução de pacotes IPv6 em IPv4. Ele necessita de uma técnica auxiliar para a conversão do DNS, chamada de DNS64 (RFC 6147). São sistemas distintos, mas que trabalham em conjunto para permitir a comunicação entre as redes IPv6 e IPv4.

O NAT64 necessita fazer a tradução de endereços IPv4 em IPv6, esta tradução é feita conforme ilustrado na figura 27. O processo é definido em detalhes na RFC 6052:

Figura 29: Endereçamento IPv6 traduzido do IPv4 pelo NAT64

Os bits 64 a 71 são reservados para a compatibilidade de identificação de host conforme a RFC 4291 e devem ser zeros.

O prefixo IPv6 pode ser escolhido pela operadora, mas é recomendada a utilização do prefixo 64:ff9b::/96, reservado especificamente para a utilização em algoritmos de mapeamento de endereços IPv4 em IPv6. Por exemplo, o IPv4 203.0.113.1 seria convertido para o endereço IPv6 64:ff9b::203.0.113.1.

Já a tradução do cabeçalho IPv6 em cabeçalho IPv4 e vice-versa é feita da mesma maneira que no IVI, já estudado anteriormente. O processo está ilustrado nas figuras 24 e 25 e é especificado em detalhes na RFC 6145.

O funcionamento do NAT64 é ilustrado no diagrama de sequência e na topologia das figuras 28 e 29, a seguir:

Figura 30: Diagrama de sequência do NAT64 / DNS64

Figura 31: Topologia de rede do NAT64 / DNS64

O NAT64 possui implementações para Linux, Windows, grandes roteadores (Cisco e Juniper) e roteadores domésticos baseados em Linux. Como exemplo serão apresentadas a seguir configurações para Linux e Cisco.

Há várias opções de implementação do NAT64 no Linux, uma delas é a desenvolvida pelo projeto Ecdysis (http://ecdysis.viagenie.ca), que também pode ser utilizada em sistemas operacionais *BSD. Apesar da necessidade de instalar um módulo ao kernel do Linux, sua instalação é bastante simples. O arquivo fonte deve ser baixado em http://ecdysis.viagenie.ca/download/ecdysis-nf-nat64-20101117.tar.gz e descompactado em uma pasta adequada, na sequência os seguintes comandos devem ser executados como root:

1. Após o download, compile o módulo do kernel:

make && make install

2. No arquivo nat64-config.sh comente as seguintes linhas:

# Load the nf_nat64 module

#modprobe -r nf_nat64

#modprobe nf_nat64 nat64_ipv4_addr=$IPV4_ADDR nat64_prefix_addr=$PREFIX_ADDR nat64_prefix_len=$PREFIX_LEN

3. Habilite o módulo do kernel:

insmod nf_nat64.ko nat64_ipv4_addr=$IPV4_ADDR nat64_prefix_addr=$PREFIX_ADDR nat64_prefix_len=$PREFIX_LEN

Os parâmetros usados acima são os seguintes:

· $IPV4_ADDR = Endereço IPv4 da interface conectada à Internet

· $PREFIX_ADDR = 64:ff9b::

· $PREFIX_LEN = 96

4. Verifique, através do comando lsmod, se o módulo foi lido corretamente. A saída do comanda deve ser algo parecido com:

Module Size Used by
nf_nat64 14542 0

5. Rode o arquivo de configuração:

./nat64-config.sh $IPV4_ADDR

6. Verifique se a interface NAT64 está “up”, através do comando ip link.
7. Pode-se testar a conectividade via NAT64 através do comando

ping6 64:ff9b::200.160.4.22

Para fazer a configuração do NAT64 em roteadores Cisco os comandos são:

Router> enable

Router# configure terminal

Router(config)# ipv6 unicast-routing

Router(config)# interface giabitethernet0/0/0

Router(config-if)# description interface towards ipv4 side

Router(config-if)# ipv6 enable

Router(config-if)# ipv6 address 64:ff9b::/96

Router(config-if)# nat64 enable

Router(config-if)# exit

Router(config)# interface giabitethernet1/2/0

Router(config-if)# description interface towards ipv6 side

Router(config-if)# ip address 192.0.2.0 255.255.255.0

Router(config-if)# nat64 enable

Router(config-if)# exit

Router(config)# nat64 prefix stateless 64:ff9b::/96

Router(config)# nat64 route 192.0.2.0/24 gigabitethernet0/0/1

Router# end

Outra opção para Linux é o projeto Linux NAT64, disponível em:

http://sourceforge.net/projects/linuxnat64/.

Um exemplo de configuração do NAT64 para roteadores Juniper está disponível em:

http://www.juniper.net/techpubs/en_US/junos10.4/information-products/topic-collections/nce/nat64-ipv6-ipv4-depletion/configuring-nat64-ipv6-ipv4-depletion.pdf;

Para o DNS64 as principais opções são o Bind (http://www.isc.org/software/bind), que possui versões para Linux e Windows, ou o Totd (http://www.dillema.net/software/totd.html), com versões para Linux e FreeBSD. Por ser mais atual e amplamente usado, o exemplo de configuração será baseado no Bind. Após a instalação do Bind, as seguintes linhas devem ser adicionadas ao arquivo de configuração :

options {

dns64 64:ff9b::/96 {

clients {any;};

mapped {any;};

suffix ::;

recursive-only yes;

break-dnssec yes;

};

Depois, basta reiniciar o Bind para que a alteração tenha efeito.

É interessante notar que o DNS64 pode apresentar problemas em sua interação com o DNSSEC. Um validador DNSSEC que não saiba lidar com o DNS64 pode rejeitar todos os dados que vêm deste, como se não fossem válidos. A RFC 6147, onde o DNS64 é definido, especifica formas de contornar o problema.

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 emhttp://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