Dentre as técnicas de transição existentes, o NAT64/DNS64 tem sido uma das mais citadas, e já vem sendo testada por alguns provedores, como a T-Mobile nos EUA. No entanto, essa técnica possui uma particularidade, ela atua em redes com endereçamento interno exclusivamente IPv6 e apesar do longo tempo desde a definição deste protocolo, existem diversas aplicações que ainda não o suportam, principalmente as voltadas para usuários finais.

Pensando nisso, resolvemos testar o funcionamento de uma série de softwares e serviços em uma rede com acesso à Internet via NAT64/DNS64, abordam os Sistemas Operacionais mais utilizados atualmente e as aplicações mais comumente utilizadas por usuários finais como, navegadores web, mensageiros instantâneos, leitores de e-mail, VoIP, além do acesso a portais web como redes sociais, webmails, video streams, portais de conteúdo, etc.

Conhecer quais aplicações podem ter seu funcionamento interrompido ou dificultado em redes com acesso seja via IPv6 ou alguma técnicas de transição pode ser fundamental no momento de definição sobre qual técnica de transição se adéqua a determinada situação, além de fornecer subsídio aos desenvolvedores de softwares para que estes compreendam quais aspectos relacionados ao IPv6 devem ser observados no momento de escreverem os códigos das aplicações.

O que é NAT64/DNS64?

O NAT64, definido na RFC6146, é uma técnica de tradução de pacotes que permite a nós somente IPv6 acessarem a Internet IPv4. Ele necessita de uma técnica auxiliar para a conversão do DNS, chamada de DNS64, definida pela RFC6147. São sistemas distintos, mas que trabalham em conjunto para permitir a comunicação entre as redes IPv6 e IPv4. O NAT64 realiza a tradução de endereços IPv4 em IPv6, de acordo com as definições da RFC6052, utilizando um prefixo IPv6 escolhido pelo provedor, ou o prefixo 64:FF9B::/96, recomendado por esta RFC (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 é baseada na especificação da RFC6145.

Para um explicação completa sobre o funcionamento do NAT64/DNS64 leia o tópico sobre técnicas de transição no endereço https://www.ipv6.br/transicao/#tecnicas-64. Nesse tópico, você encontrará informações sobre diversas implementações desta técnica de transição, inclusive a do projeto Ecdysis (https://ecdysis.viagenie.ca), cuja versão e exemplos de configuração foram utilizada nos experimentos citados neste post.

Descrição dos testes

Conforme ilustrado a seguir, o cenário dos testes foi composto por um roteador Cisco 1941, com IOS 15.0(1)M3, responsável pela conexão da Rede IPv6 à Internet. Um servidor responsável pela tradução dos pacotes via NAT64 e pelas respostas as requisições DNS via DNS64. Como gateway da Rede IPv6, foi utilizado um roteador D-Link DIR-655 XTREME N GIGABIT ROUTER Rer. B1, com firmware 2.06b02, que permitia conexões sem fio ou através de quatro portas Gigabit Ethernet. Este roteador anunciava via mensagens Router Advertisement o prefixo 2001:12FF:6:64::/64, além do endereço do servidor DNS64, o 2001:12FF:6:1::1. A princípio, nenhuma informação para configuração de rede IPv4 foi enviada.

As estações eram compostas por três desktop, instalados com Microsoft Windows Vista Ultimate, Microsoft Windows 7 Professional SP1 e Ubuntu Desktop 10.04 LTS (kernel 2.6.32.41), além de três laptopsinstalados com Microsoft Windows XP Professional SP3, Mac OS X Snow Leopard (versão 10.6) e Mac OS X Lion (versão 10.7).

Importante salientar que não foram instaladas nas estações quaisquer aplicações que de alguma forma alterassem a pilha IPv6 ou seu funcionamento. Do mesmo modo não foram configurados túneis, gateway de aplicação ou proxies, para acessar conteúdos na Internet IPv4, com o intuito de se ter a percepção correta do funcionamento das aplicações em uma rede somente IPv6 e NAT64/DNS64.

Para configurar do NAT64 foi utilizada a implementação desenvolvida pelo projeto Ecdysis (https://ecdysis.viagenie.ca). Apesar de existirem outras implementações como CISCO, JUNIPER e o Linux NAT64 (https://sourceforge.net/projects/linuxnat64/), a escolha do projeto Ecdysis deveu-se pelo fato desta implementação ser open-source e disponível para instalação em GNU/Linux e BSD.

Como servidor DNS utilizou-se o software BIND em sua versão 9.9.0. Optou-se por sua utilização dado que esta versão possui suporte para responder às requisições por endereços IPv6, para responder às requisições através de conexões IPv6 e ao DNS64, além de ser o software DNS mais utilizado da Internet. O prefixo utilizado para responder as requisição ao DNS64 foi o 2001:12FF:6:1:64:0::/96 e para atender os demais requisitos dos testes, a única alteração necessária à configuração do BIND foi a adicionar as seguintes opções:

options { listen-on-v6 { any; }; dns64 2001:12FF:6:1:64:0::/96 { clients { any; }; }; };

Do mesmo modo que os testes realizados por Arkko e Keranen, descritos na RFC6586, foram analisados no cenário descrito anteriormente, o funcionamento de diversos serviços e aplicações comumente utilizados por usuários finais. Observou-se o comportamento de diversos tipos de aplicações como navegadores web, cliente de e-mail, mensageiros instantâneos, aplicações VoIP, de compartilhamento de arquivos, entre outros, verificando através do analisador de protocolos de rede WireShark o fluxo de troca de pacotes e requisições DNS para melhor compreender o funcionamento ou não dos softwares testados.

Apresentação e análise dos dados

A primeira análise realizada foi referente à autoconfiguração do endereçamento IPv6 nas interfaces de rede. Exceto as versões do Microsoft Windows Vista e 7, todos os demais sistemas apresentaram problemas devido à inexistência de endereçamento IPv4.

No ambiente Ubuntu observou-se que sem as configurações de endereçamento IPv4, não foi possível obter conectividade com a rede. Foi necessária a instalação do daemon avahi-autoipd para que fosse gerado um endereço link-local IPv4 baseado no prefixo 169.254.0.0/24 e a interface de rede se iniciasse. Em seguida, as configurações de endereçamento IPv6 foram estabelecidas automaticamente via Router Advertisement, porém, o endereço do servidor DNS recursivo não foi aprendido, sendo configurado manualmente no arquivo resolv.conf. Uma solução para a aprendizagem automática do endereço do servidor DNS recursivo seria a instalação do daemon rdnssd na estação.

No Mac OS X, tanto o Lion quanto o Snow Leopard apresentaram comportamentos similares ao Ubuntu no que se refere à configuração inicial das interfaces de rede. Para contornar este problema e realizar um teste comparativo, habilitou-se no roteador D-Link o envio, via DHCP, de um endereço IPv4 privado e não roteável. Consequentemente, as interfaces iniciaram e as configurações IPv6 foram estabelecidas. Em seguida, o endereço IPv4 foi retirado manualmente, porém, a conectividade e o funcionamento das interfaces de rede não foram interrompidos. Importante destacar que no Mac OS X Lion, o endereço do servidor DNS recursivo foi aprendido automaticamente através do envio da mensagem Router Advertisement, o que não ocorreu com Snow Leopard, onde foi necessária a configuração manual deste endereço.

Comportamento similar também ocorreu com a configuração da interface de rede no Microsoft Windows XP onde, sem a existência de um endereço IPv4, não foi possível estabelecer conectividade com outras redes, mesmo com o endereço IPv6 sendo aprendido automaticamente. Tentou-se a mesma solução adotada com os sistemas Mac OS X, obtendo um endereço IPv4 via DHCP, no entanto, após a retirada do endereço IPv4 a conectividade ficou prejudicada. Foi necessário adicionar o endereço IPv6 do servidor DNS recursivo manualmente, porém, mesmo havendo conectividade com o servidor as requisições de resolução de endereços não eram realizadas. Deste modo, sem conseguir realizar consultas ao servidor DNS64, não foi possível realizar os demais testes propostos neste trabalho, notando-se que só era possível obter conectividade acessando outros serviços diretamente via IP. Por exemplo, foi possível acessar site v4.ipv6.br digitando no navegador web seu endereço IP no formato https://[2001:12FF:6:1:64:0:200.160.4.22]. Outros sites foram acessados seguindo este formato, contudo, notou-se que alguns conteúdos não apareciam corretamente, como imagens, anúncios publicitários entre outros recursos.

Os testes relacionados à navegação web ocorreram sem nenhuma “quebra” de funcionalidade, tanto nas páginas acessadas, seja via HTTP ou HTTPS, quanto nos navegadores utilizados. Para este teste foram utilizados os navegadores Mozilla Firefox, Google Chrome, Safári e Internet Explorer (de acordo com o suporte de cada plataforma), e acessados diversos portais e serviços como uol.com.br, ig.com.br, terra.com.br, gmail.com, twitter.com, facebook.com, flickr.com, youtube.com, zappiens.br, entre outros. A ilustração a seguir mostra a navegação no domínio v4.ipv6.br, acessível apenas via IPv4, onde é possível observar que apesar de utilizarmos apenas endereçamento IPv6, o servidor acessado indica que está recebendo requisições via IPv4.

Testou-se também o recebimento e o envio de e-mails através do cliente Mozilla Thunderbird 12.0, configurando uma conta sob o domínio gmail.com, via IMAP e SMTP, e outra sob o domínio bol.com.br, via POP3 e SMTP. Também não foram relatados problemas na utilização deste serviço. Tanto o recurso de autoconfiguração de contas bem como a troca de e-mails ocorreu normalmente. A ilustração a seguir representa o fluxo de troca de mensagens entre a estação e os servidores de e-mail, sendo possível observar o endereço IPv4 dos servidores mapeados em IPv6.

Em relação aos protocolos utilizados por mensageiros instantâneos e VoIP, foram avaliados o Micrisoft MSN, Google Talk e Skype. Para utilizar o MSN e o Google Talk no Ubuntu, as contas foram configuradas através do mensageiro Pidgin 2.10.3.

O Skype, para iniciar a conexão com seus servidores, realiza uma consulta DNS requisitando um registro do tipo A para o nome de domínio dsn12.d.skype.net. Como se obtém somente endereços IPv4 como resposta, a conexão é interrompido e o serviço não pode ser utilizado em nenhuma plataforma testada.

Ao se conectar através dos endereços IPv6 válidos de seus servidores, o Google Talk funcionou corretamente, no entanto, notou-se que utilizando endereços IPv4 mapeados e a tradução de pacotes não foi possível estabelecer a comunicação entre cliente e servidor.

A utilização do MSN também não ocorreu em nenhuma plataforma. Analisando o fluxo de dados entre o cliente e o servidor, é possível observar que há o estabelecimento de conexão entre eles, mas em um determinado momento, é enviada uma mensagem pelo servidor contendo um endereço IPv4 em seu formato literal e a comunicação se encerra. Este comportamento pode ser verificado na ilustração a seguir.

Nos testes realizados em softwares de compartilhamento de arquivos, todas as aplicações apresentaram suporte ao IPv6, sendo analisados os softwares Miro, µTorrente e Transmission. No entanto, alguns comportamentos precisam de uma análise mais aprofundada e um conhecimento maior de suas funcionalidades.

Observando o funcionamento do µTorrent, notou-se que existiam apenas conexões com peers que possuíam endereçamento IPv6 nativo, presumindo-se que não sejam utilizadas resoluções de nomes para localizá-los. As conexões com os trackers, servidores que auxiliam na localização dos peers para troca de arquivos, foram estabelecidas normalmente, exceto quando o endereço do servidor era expresso no formato IPv4 literal.

Em relação ao software Transmission, todos os peers conectados utilizavam endereços da técnica de transição Teredo e a lista de trackers indicava que nenhum deles estava disponível. Este comportamento demonstra que a busca por peers deve ocorrer de outras formas, não somente via trackers, e sua localização apenas através de seus endereços IPv4, por isso a utilização de túneis Teredo para realizar a conexão. Para se conectar aos servidores, provavelmente, seja esperado um endereço IPv4 literal, de modo que a utilização de NAT64/DNS64 não seja eficiente para o estabelecimento da conectividade.

Também foi testado o software de armazenamento e compartilhamento de arquivos Dropbox. Sua utilização pode ocorrer de duas formas: através do acesso via página web, onde é possível realizar o download e o upload de arquivos para armazená-los em servidores disponíveis na Internet; e através da utilização de um software instalado nas estações, que permite a sincronização dos arquivos salvos entre as estações e o servidor. Seu primeiro modo de utilização funcionou normalmente, no entanto, a utilização via software apresentou problemas devido a uma requisição DNS por um registro do tipo A para se obter o endereço do servidor. Este comportamento impossibilitou seu funcionamento na rede com NAT64/DNS64.

Diversos outros serviços e protocolos funcionaram de modo satisfatório utilizando os endereços mapeados e a tradução dos pacotes. Durante os teste foi possível realizar streaming de vídeo utilizando o software VLC, transferência de arquivos via protocolo FTP, acessos remotos utilizando SSH, sincronização dos relógios dos computadores através do protocolo NTP e realizar as atualizações dos sistemas Microsoft Windows.

Conclusão

O intuito deste post foi mostrar o funcionamento das principais aplicações e serviços utilizados por usuários finais via Internet, através de uma rede apenas com endereçamento IPv6, utilizando para obter conectividade com a Redes IPv4 a técnica de transição NAT64/DNS64. Buscou-se observar se, devido às características de acesso da rede, tais serviços e aplicações teriam seu funcionamento interrompido ou prejudicado, avaliando o impacto da adoção de uma técnica de transição onde somente endereços IPv6 são atribuídos às interfaces de rede. Foram testados portais web, de streaming de vídeos, redes sociais, além de aplicações para compartilhamento de arquivos, mensageiros instantâneos, VoIP, entre outros, utilizando as versões mais recentes dos aplicativos e os Sistemas Operacionais com maior penetração de mercado atualmente.

Os testes iniciais, relacionados à obtenção dos parâmetros de configuração de rede, demonstraram que as implementações dos Sistemas Operacionais não trazem as funcionalidades das pilhas IPv4 e IPv6 totalmente separadas. Exceto os sistemas Windows Vista e Windows 7, todos os demais não foram capazes de iniciar as interfaces de rede e estabelecer conectividade sem a adição de um endereço IPv4. Foram necessárias configurações manuais para que as interfaces funcionassem apenas com endereços IPv6, sendo que no caso do Windows XP, este fato impossibilitou a realização dos teste, visto que, sem endereçamento IPv4 a conectividade era praticamente nula. Notou-se também, que apesar do endereço do servidor DNS recursivo ser enviado pelo roteador via mensagem Router Advertisement, somente o MAC OS X Lion adicionou automaticamente esta informação a sua configuração.

Em relação à técnica de transição NAT64/DNS64, os testes com navegadores web, com o acesso aos mais diversos portais, com a utilização de clientes de e-mail e de outros protocolos como FTP, SSH e NTP, não apresentaram problemas com o uso de endereços IPv4 mapeados em IPv6, pelo DNS64, nem com a tradução de pacotes feita pelo NAT64. No entanto, outras aplicações apresentaram falhas em seu funcionamento.

Através da análise do fluxo de dados gerado pelas aplicações, notou-se que algumas realizavam requisições específicas por endereços IPv4 ao servidor DNS, inviabilizando o seu funcionamento em redes unicamente IPv6 ou com DNS64 configurado. Outras provavelmente possuam em seu código fonte parâmetros exclusivamente IPv4, visto que respostas enviadas pelos servidores das aplicações retornaram endereços IPv4 no corpo de suas mensagens. Também se observou que algumas aplicações funcionaram normalmente ao se conectarem a servidores utilizando endereços IPv6 válidos como destino, porém, se a conexão utilizasse endereços mapeados e pacotes traduzidos via NAT64/DNS64, a comunicação não se estabelecia.

Os resultados obtidos neste trabalho encontraram-se muito próximos aos obtidos nos testes realizados por Arkko e Keranen em 2010 (RFC6586), demonstrando que não houve por parte dos desenvolvedores das aplicações testadas, uma preocupação maior em adicionar suporte ao protocolo IPv6 em seus softwares.

Deste modo, foi possível concluir que a adoção de uma rede unicamente IPv6 hoje, não ocorreria de forma imperceptível para o usuário final, obrigando-o a realizar configurações manuais para obter conectividade. Concomitante a isso, notou-se que a grande maioria do conteúdo existente na Internet ainda esta acessível apenas via IPv4. Para equacionar esta questão, a utilização da técnica de transição NAT64/DNS64 se demonstrou eficaz nos testes de navegação básica como acesso às páginas web e na utilização de clientes de e-mail. No entanto, sua utilização não soluciona o problema relacionado aos softwares que ainda não apresentam suporte ao protocolo IPv6.

Os testes realizados apresentaram um pequeno panorama do suporte ao IPv6, mas muitos outros pontos ainda precisam ser avaliados. Por exemplo, a ampliação do âmbito dos testes realizados, atuando também em dispositivos móveis e aplicações voltadas à administração e ao núcleo das redes. Além disso, testar ambientes com outras técnicas de transição implantadas, que atuem não somente em redes puramente IPv6, mas que façam uso de túneis, compartilhamento de endereços IPv4, etc., de modo a demonstrar o funcionamento das aplicações nestes cenários.