Implementação de um mecanismo de tradução de protocolos (IPV4 e IPV6) - NAT-PT/DNS-ALG

Julio Gustavo Soares Firmo da Costa <tuanjulio@yahoo.com>
Sergio Vianna Fialho <fialho@pop-rn.rnp.br>

Ponto de Presença do Rio Grande do Norte (POP-RN)
Universidade Federal do Rio Grande do Norte (UFRN)

1. Introdução
2. Aspectos da transição do IPV4 para o IPV6
3.O Gateway de aplicação DNS-ALG (um componente do gateway de tradução)
3.1 Análise de requisitos para o DNS-ALG
3.2 Especificação formal do DNS-ALG
3.3 Aspectos de implementação e testes
4. Conclusão
Referências bibliográficas

1. Introdução

O Internet Protocol version 6 [1] é o protocolo de nível de rede que foi desenvolvido pelo IETF para substituir a versão 4. Esse protocolo já vem sendo implementado em vários sistemas operacionais, sobretudo nos mais comumente usados. A comunidade tem cooperado no desenvolvimento deste protocolo, para torná-lo o padrão na Internet a exemplo do IPv4. Tem cooperado também na definição de mecanismos que diminuam o impacto e as dificuldades que o processo de migração da versão quatro para a versão seis ocasionam, pois as duas não são totalmente compatíveis.

O conteúdo deste documento é reflexo do trabalho que vem sendo desenvolvido no Ponto de Presença do Rio Grande do Norte (PoP-RN), referente à implementação e à documentação de soluções que operacionalizam o IPv6. Mais especificamente, aqui apresenta-se uma especificação para o software DNS-ALG (Domain Name Service - Application Level Gateway), que está em desenvolvimento para, em conjunto com os mecanismos de transição dos protocolos, vir a permitir transparência na interação entre as aplicações que estejam funcionando sobre qualquer um dos protocolos (IPv6 ou IPv4).

2. Aspectos da transição do IPV4 para o IPV6

Existem dois escopos para o foco de desenvolvimento destes mecanismos de transição[2]: primeiro, a comunicação entre domínios puramente IPv6 mediante uso de tunelamento via ambientes puramente IPv4; segundo, a comunicação de domínios cuja infra-estrutura de redes seja diferente, ou seja, um domínio IPv4 e outro IPv6, utilizando mecanismos dual-stack. Para este trabalho, iremos nos centrar neste segundo escopo. Para resolver os problemas de comunicação neste contexto, existem basicamente quatro propostas de configuração das máquinas envolvidas a serem observadas[3]. A proposta que seguimos para este trabalho é a de uso de um gateway capaz de tornar possível a comunicação entre máquinas puramente IPv4 com máquinas puramente IPv6, ou seja, através da utilização de um gateway de protocolo [4].

A preocupação em permitir comunicação entre máquinas puramente IPv4 com máquinas puramente IPv6 até o nível da camada de aplicação se justifica, uma vez que, por algum tempo, ambos os protocolos deverão co-existir na Internet. Portanto, para que seja possível o compartilhamento de serviços no nível de aplicação de forma transparente, técnicas como a tradução de protocolos vêm sendo desenvolvidas. Por fim, o emprego desta técnica permite que as aplicações dos usuários não precisem ser configuradas para trabalhar, ora com o IPv6, ora com o IPv4. Uma vez que isto seja conseguido, todos os serviços, por exemplo, os da Web - os mais utilizados - poderão ser compartilhados pelas duas infra-estruturas de redes.

3. O Gateway de aplicação DNS-ALG (um componente do gateway de tradução)

O cenário que foi concebido para o desenvolvimento deste trabalho refere-se a um ambiente puramente IPv6, buscando acessar serviços que estão fora de seu domínio. O destino tanto poderá ser uma máquina IPv4 quanto uma máquina IPv6. Para tanto, iremos utilizar um gateway de tradução de protocolo cuja configuração será aquela proposta na RFC2766, onde é sugerido a utilização do NAT-PT (Network Address Translation - Protocol Translation), cuja funcionalidade garante a transparência ao nível da camada de rede, dentro de suas limitações como expostas na RFC citada. Neste ponto, por exemplo, caso o usuário soubesse os endereços IPv6 IPv4-Compatível e IPv4 associados ao domínio IPv4 e ao domínio IPv6, respectivamente, já seria possível a utilização direta de serviços que fossem compartilhados por qualquer dos domínios.

No entanto, a utilização direta de endereços IP não é convencional nas aplicações dos usuários, e sim o uso de nomes de alto nível. Como a finalidade é elevar a transparência até o nível de aplicação, é incluído neste gateway um outro tradutor de protocolo, como também é sugerido na RFC2766, para resolver a dificuldade de resolução de nomes, o DNS-ALG. A pilha de protocolos deste gateway está representada na figura 1.

Figura 1 - Pilha do Gateway de Protocolo conforme recomendação da RFC2766.

Em parte, estes recursos podem ser encontrados no software NAT-PT, desenvolvido por Steve Mottran [5], cuja implementação data de abril de 1999. No entanto, neste trabalho, se apresenta o desenvolvimento de um DNS-ALG seguindo recomendações mais recentes contidas na RFC2766 (de fevereiro de 2000) e nos drafts que a comentam [6], abordando as possíveis falhas e suas respectivas soluções no que tange às características de implementação deste ALG.

3.1 Análise de requisitos para o DNS-ALG

O DNS-ALG deverá ser capaz de traduzir uma consulta do DNS do tipo AAAA, vinda de um cliente localizado no ambiente IPv6, para uma consulta do tipo A, caso o servidor de nomes a ser consultado se encontre no ambiente IPv4. Ao receber uma resposta IPv4, o DNS-ALG deve mapeá-la em um endereço IPv6 IPv4-Compatível. O processo inverso também deve ser tratado, pois máquinas que estejam em um domínio puramente IPv4 ao requererem a resolução de nomes para endereços IPv4 esperam sempre endereços IPv4 de resposta, ainda que estes nomes referenciem serviços que estejam em domínios puramente IPv6. Isso também ocorre com solicitações oriundas de domínios puramente IPv6. Desta forma, torna-se necessário, para se chegar à transparência ao nível da camada de aplicação, a existência de um dispositivo capaz de permitir a resolução de nomes para domínios diferentes do seu. Este dispositivo é o gateway NAT-PT/DNS-ALG.

3.2 Especificação formal do DNS-ALG

A figura 2 apresenta, através do formalismo das máquinas de estado, uma especificação para o DNS-ALG. Logo após a figura, detalham-se os casos de operação do mesmo.

Figura 1 - Especificação Formal para o DNS-ALG que vem sendo desenvolvido no PoP-RN.

Caso Geral - Chegada de mensagens de consulta ao DNS

No gateway está sempre rodando o daemon do DNS-ALG (estado LISTEN) que verificará se a mensagem de DNS refere-se a uma consulta ou a uma resposta (estado TYPE of message). Dependendo do caso, o daemon invoca o processo correspondente: process_query ou o process_answer.
Caso 1 - Chegada de consulta Process_Query

Neste caso, será verificado o campo CLASS das requisições (estado VERIFY CLASS). Se a classe for do tipo IN, a execução continua. Caso contrário, a mensagem é descartada e o processo é encerrado. Das consultas aceitas são extraídas informações e armazenadas na tabela tab_query (estado STORE), para posterior associação da resposta à pergunta. Em seguida, verifica-se o campo TYPE do registro de recurso e qual o destino da requisição, através de consulta feita à tabela de roteamento do IP (estado VERIFY TYPE & SIDE), se para fora ou não do domínio do IPv6. Qualquer consulta com registro de recurso onde o tipo seja diferente de A ou AAAA, será descartada. Em breve, serão tratadas consultas do tipo MX.

Caso 1.1 - Requisição AAAA, vinda do domínio IPV6, para fora do mesmo

Nesse caso, a flag transl é "setada" (valor yes) para orientar a condução posterior do processo. A seguir aloca-se um endereço IPv4 para endereço de origem (estado ALOC), para o casamento da resposta, armazenando-o em tab-query. No estado FORWARD query, entretanto, é transmitida uma consulta de valor AAAA imediatamente, pois esta é a situação definida como prioritária, enquanto o processo aguarda (estado SLEEP) por um tempo predeterminado, antes de proceder à tradução indicada (estado TRANSL 6 4). Essa tradução é abortada (estado ABORT) caso tenha havido uma resposta à consulta AAAA enviada prioritariamente (estado VERIFY tab_query). Em caso contrário, o retorno ao estado FORWARD query (com transl "ressetada" - valor no) provoca, agora, o envio de uma nova consulta tipo A e a terminação do processo (estado FINISH).

Caso 1.2 - Requisição AAAA, vinda de domínio IPV6 externo, para domínio IPV6 interno

Como o destino é para dentro (to in) do domínio v6, a flag transl é "ressetada" (valor no) de forma a indicar situação de término do processo, após envio da consulta AAAA.

Caso 1.3 - Requisição A, vinda de domínio IPV4 externo, para domínio IPV6 interno

Como o destino é para dentro (to in) do domínio v6, a flag transl é "ressetada" (valor no), a tradução é realizada, do valor A para AAAA (estado TRANSL 4 6) e a consulta é encaminhada. Após o envio da mensagem, o processo chega ao estado final (FINISH).

Caso 2 - Chegada de respostas: Process_Answer

Se for verificada que trata-se de uma resposta, o processo de tratamento de resposta é invocado pelo daemon. A primeira ação é remover as informações referentes a esta resposta na tabela tab_query e armazená-las temporariamente em outro lugar para serem descartadas assim que o processo encerrar. Verifica-se, então, o tipo da resposta (A ou AAAA) e compara-se com as informações recuperadas da tabela. Em função desta comparação é feita a tradução adequada, quando necessário, e encaminha-se a resposta ao cliente DNS adequado. Após a mensagem ser encaminhada, o processo termina (estado FINISH).

3.3 Aspectos de implementação e testes

O gateway NAT-PT/DNS-ALG, para poder resolver as traduções de protocolo, deve ser o roteador default do servidor de DNS no domínio IPv6.O tráfego que passa por este roteador (NAT-PT/DNS-ALG) é o tráfego relativo às consultas e respostas de DNS (resolução de nomes para fora do domínio) e o tráfego devido à comunicação das máquinas internas com máquinas que estejam em um domínio IPv4 [6]. A comunicação entre máquinas do domínio IPv6 com máquinas que estejam em um outro domínio IPv6 será feita via túnel por um outro roteador. Para a implementação do componente DNS-ALG, foi escolhida a linguagem de programação C, dado o enfoque procedural adotado em seu desenvolvimento e devido à facilidade de integração de programas desenvolvidos em C com o sistema operacional Linux. O componente NAT-PT usado é o desenvolvido por Steve Mottran.

O ambiente de teste já implementado constitui-se de uma ilha puramente IPv6, com quatro máquinas, com acesso à Internet. Em duas delas, foram implementados serviços de Web e ftp. Uma outra é o roteador em que será implementado o túnel com o BR6bone e a quarta foi dedicada para ser o gateway NAT-PT/DNS-ALG.

4. Conclusão

A especificação do DNS-ALG está sendo concluída e, em breve, será possível se passar à implementação propriamente dita. Foram encontradas dificuldades para instalar o NAT-PT do Steve Mottran, devido a problemas de compilação. No entanto, tem-se buscado soluções para esta dificuldade.

Após a realização dos testes em ambiente de laboratório e depuração do programa, pretende-se buscar a colaboração de outros grupos dentro da RNP, em outros nós do BR6Bone, para a realização de testes de campo e verificação do desempenho da solução desenvolvida. Essa especificação do DNS-ALG abordou questões ainda não explorado nas RFCs, como o tratamento de querys e answers observando o seu destino, traduzindo os tipos A e AAAA quando necessário.

Observou-se, também, um possível tratamento a ser dado, futuramente, ao tipo MX.

Referências bibliográficas

[1] DEERING, S.; HINDEN, R. Internet Protocol, Version 6 (IPv6) Specification. RFC 2460, dec. 1998. Disponível em: <http://www.ietf.org/rfc/rfc2460.txt?number=2460>. Acesso em jul. 2003.

[2] GILLIGAN, R.; NORDMARK, E. Transition Mechanisms for IPv6 Hosts and Routers. RFC 2893, aug. 2000. Disponível em: <http://www.ietf.org/rfc/rfc2893.txt?number=2893>. Acesso em jul. 2003.

[3] SAVOLA, P. Migration and Co-existence of IPv4 and IPv6 in Residential Networks. Disponível em:<http://staff.csc.fi/~psavola/residential.html>. Acesso em jul. 2003.

[4] TSIRTSIS, G.; SRISURESH, P. Network Address Translation - Protocol Translation (NAT-PT). RFC 2766. Disponível em: <http://www.ietf.org/rfc/rfc2766.txt?number=2766>. Acesso em jul. 2003.

[5] LINUX-BASED USERSPACE NAT-PT. Korean IPv6 Deployment Project. Disponível em: <http://www.ipv6.or.kr/english/natpt-overview.htm>. Acesso em jul. 2003.

[6] HALLIN, P.; SATAPATI, S. NAT-PT DNS ALG solutions. draft-hallin-natpt-dns-alg-solutions-01.txt. Disponível em: <http://www.ietf.org/mail-archive/ietf-announce/Current/msg19741.html>. Acesso em jul. 2003.