Transição
1. Introdução
O IPv4 e o IPv6 não são diretamente compatíveis, já que 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, os protocolos podem funcionar em paralelo nos mesmos equipamentos, possibilitando realizar a transição de forma gradual.
Desse modo, logo que o IPv6 estivesse pronto, sua implantação começaria a ser feita aos poucos com o IPv4 ainda funcionando. Esse cenário é chamado de pilha dupla, ou dual stack. Quando o IPv6 estivesse implantado em todos os dispositivos, o IPv4 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á é 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 sem endereços IPv4 livres para atendê-los. Assim, novas técnicas auxiliares foram e continuam sendo desenvolvidas.
2. Classificação das técnicas de transição
O período de transição e de coexistência entre os protolocos IPv6 e IPv4 exigiu o desenvolvimento de técnicas auxiliares, inicialmente para resolver problemas de como conectar as novas redes IPv6 com o conteúdo das demais redes majoritariamente IPv4. Com o aumento da adoção do IPv6, essa cenário se inverterá e técnicas para garantir o acesso IPv6 a redes IPv4 legadas surgirão. Além disso, existe um terceiro tipo de técnica que busca aumentar a sobrevida do IPv4 enquanto a transição completa não ocorre.
As técnicas de transição podem ser classificadas segundo sua funcionalidade:
- 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.
Essas técnicas podem ser classificadas, ainda, entre stateful e 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. Já técnicas stateless não tem essa necessidade, 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.
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. De forma geral, os critérios que devem ser utilizados na escolha da técnica a ser utilizada, são:
- 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;
- preferir técnicas stateless em detrimento de técnicas statefull;
- evitar técnicas para prolongar o uso do protocolo IPv4, sem a adoção concomitante do IPv6;
- analisar a adequação da técnica à topologia da rede onde será aplicada e
- 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.
A seguir são apresentadas algumas técnicas importantes, clique nas que interessar para saber mais sobre elas:
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 3.1.
Figura 3.1: 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 (RFC 8305). 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.
4. Túneis
Túneis 6over4 (IPv6-over-IPv4)
Quando a utilização de pilha dupla não é possível, uma das alternativas é 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 4.1 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 4.1: funcionamento 6over4
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 é:
Figura 4.2: 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.2
ip link set dev
toHostB upip -6 route add 2001:db8::b0ca dev toHostB
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
Figura 4.3: 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
ipv6 unicast-routing ipv6 route 2001:db8:20::/64 2001:db8:100::2
configure terminal
interface 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
Túneis GRE
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 em https://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 4.4: 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
tunnel mode gre
Tunnel Broker
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:
- https://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.
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 4.5: Topologia lógica do Tunnel Broker
Figura 4.6: 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
. /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 "https://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
uci set network.lan.ip6addr=2001:470:1f0b:9999::1/64
uci commit
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
ping6 ipv6.google.com
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
5. NAT444
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.
Do ponto de vista estritamente técnico, é importante considerar 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 cedeu o bloco 100.64.0.0/10 em questão RFC 6890.
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 5.1: Topologia de rede NAT444
6. NAT64, DNS64 e 464XLAT
NAT64 e DNS64
Essa técnica de tradução é aplicável em situações para nós somente IPv6 acessarem a Internet IPv4. O NAT64 (RFC 6146) é 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, o processo é definido em detalhes na RFC 6052.
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 7915.
O funcionamento do NAT64 é ilustrado no diagrama de sequência e na topologia das figuras 28 e 29, a seguir:
Figura 6.1: Diagrama de sequência do NAT64 / DNS64
Figura 6.2: 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 (https://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 https://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
Para o DNS64 as principais opções são o Bind (https://www.isc.org/software/bind), que possui versões para Linux e Windows, ou o Totd (https://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.
464XLAT
O 464XLAT (RFC6877) é 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 6.3: Diagrama de sequência do 464XLAT
Figura 6.4: 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. Como o prefixo utilizado é um /96 a autoconfiguração stateless não é possível e é necessário a utilização de DHCPv6 para a atribuição de endereços. O CLAT pode ser implementado no CPE ou em celulares. Para a implementação em celulares existe um projeto disponível para Android em https://code.google.com/p/android-clat/. Para a implementação em CPE pode-se utilizar o IVI (https://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.
7. 6to4 e Teredo
6to4
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.
A técnica funcionou parcialmente e ainda é usada na Internet, mas apresenta diversos problemas. Dentre eles estão a qualidade com relays públicos e problemas de segurança, além disso, 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, por exemplo, firewalls ou outras medidas de segurança podem ser 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. O Brasil é um exemplo desse problema, aqui não há relays públicos 6to4, assim, os pacotes podem ir para localidades distantes como América do Norte ou Europa, mesmo que a origem e o destino estejam no país.
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 0x00. 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 0x01.
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.
Teredo
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, pois não é muito eficiente e tem alta taxa de falhas, além de algumas considerações de segurança. Assim como o 6to4, o Teredo pode permitir que tráfego que seria bloqueado em IPv4 consiga chegar ao destino.Recomenda-se que seja desabilitado em redes corporativas
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.
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 0x00. O bit 2 (do menos significativo para o mais significativo) deve ser mudado para 1, para desabilitar o Teredo.
8. Outras técnicas
Dual Stack Lite (DS-Lite)
O Dual Stack Lite (Pilha dupla simplificada), padronizada na RFC 7335. Ela pode ser aplicada em situações em que o provedor tem sua rede nativa em IPv6 e já oferece IPv6 nativo para seus usuários. Assim, o usuário terá acesso nativo ao IPv6, mas não ao IPv4. Quando quiser acessar um conetúdo IPv6, o CPE do usuário, chamado na técnica de B4 (DS-Lite Basic Bridging BroadBand), é responsável por criar um túnel transmitindo o pacote pela rede IPv6 do provedor; ao chegar na borda, um outro equipamento denominado AFTR (Address Family Transition Router) implementa um CGN (Carrier Grade NAT), que é um NAT, permite que o pacote chegue ao seu destino fornecendo um endereço IPv4 válido para o pacote. Na resposta, o caminho inverso é feito e não há problemas com o uso de IPv4 repetidos, já que os túneis são identificados pelo endereço único IPv6 do usuário.
IVI, dIVI e dIVI-pd
O dIVI e o dIVI-pd é útil para provedores que precisam fornecer acesso IPv4 aos seus usuários, mesmo sem endereços. Para isso é utilizada uma técnica stateless baseada na dupla tradução de pacotes. Ambas as soluções são extensões do IVI (RFC6219), técnica desenvolvida por pesquisadores da CERNET2, a rede acadêmica chinesa, que é somente IPv6. Os nós atendidos por essas técnicas usam pilha dupla, tendo IPv6 nativo para a comunicação com a Internet IPv6 e um IPv4 compartilhado. A diferença entre as técnicas é que o dIVI-pd permite designar um prefixo IPv6 no lugar de um só endereço, permitindo o uso da autoconfiguração stateless, o endereço IPv4 atribuido ainda é um só, e nesse caso será necessário o uso de NAT.
4rd
O 4rd é uma solução similar ao DS-Lite, usando 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 em outra técnica, o 6rd (RFC5969).
6PE e 6VPE
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. Para resolver essa questão existem as técnicas 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).
6rd
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.
ISATAP
ISATAP (sigla para Intra-Site Automatic Tunnel Addressing Protocol) é uma técnica de tunelamento que liga dispositivos a roteadores. Definida na RFC 5214, 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. Esta técnica, é 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.\
A+P
Essa técnica assim como o NAT444 pode ser usada, em conjunto com a implantação nativa do IPv6, para garantir conectividade IPv4 dos usuários, numa Internet em transição.
A técnica Address Plus Port (A+P) significa endereço mais porta e está definida na RFC 6346, permitindo compartilhar 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. A utilização de A+P, se possível, é preferível à utilização do NAT444. É importante lembrar que a utilização dessas técnicas deve ser sempre acompanhada da implantação do IPv6.
Compartilhe
