O IPv6 - Transição IV

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 URL http://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 emhttp://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.