Resumo

  • O NAT podia economizar endereços IPv4 globalmente únicos na borda da rede, mas aplicativos que dependiam desses valores precisavam de mais do que a reescrita do cabeçalho IP.
  • A pergunta histórica da RFC 2993 era quem faria o trabalho restante: gateways de aplicação, atualização coordenada de pontos finais, gestão local de nomes e suporte — e não apenas um aparelho no caminho do roteador.

Um tradutor pode executar a reescrita configurada sem erro e, ainda assim, deixar um aplicativo sem conexão. A tabela de tradução talvez não esteja errada. O problema pode surgir quando o mesmo endereço identifica um equipamento dentro da rede privada, vira outro valor do lado público e continua aparecendo no conteúdo das mensagens do aplicativo.

Essa tensão já existia na proposta de 1994. A RFC 1631 apresentou Network Address Translation como uma resposta incremental à pressão sobre os endereços IPv4: redes de borda poderiam reutilizar endereços internos, enquanto um equipamento de fronteira traduziria apenas o tráfego que saísse para o espaço global. O texto também reconhecia a troca envolvida. O significado de ponta a ponta do endereço IP diminuía e a rede passava a manter estado adicional. Em locais com mais de uma saída, os tradutores precisavam compartilhar uma visão consistente dos mapeamentos. Era uma ponte prática, não uma arquitetura sem custo.

Em novembro de 2000, Tony Hain revisitou o NAT após seis anos de interesse e implantação crescentes na RFC 2993. A questão já não era somente se um roteador conseguia substituir um endereço por outro. Era se o serviço continuaria funcionando quando esse endereço aparecesse em um lugar que o tradutor não inspecionava.

A resposta dependia do aplicativo. Uma comunicação simples entre dois pontos finais passando por um único NAT podia ser administrável. Mas certos protocolos carregavam endereços IP no conteúdo; outros dependiam da consistência do cabeçalho para somas de verificação, autenticação ou segurança. Um tradutor que só examinasse o cabeçalho não conseguiria corrigir todas essas premissas. Gateways de camada de aplicação (ALGs) e proxies podiam ajudar, mas cada um precisava compreender o protocolo que pretendia reparar. A RFC 2775 já havia feito observação semelhante no início daquele ano: uma ALG ou um proxy precisaria ser atualizado quando surgisse um novo aplicativo dependente de endereços.

“Transparente”, então, passou a ser uma promessa condicionada. Se o aplicativo não expusesse nem dependesse do endereço traduzido, a função na borda poderia passar despercebida. Caso contrário, alguém teria de coordenar a solução em todos os lugares onde o aplicativo rodasse. A RFC 2993 contrapõe o caso relativamente simples de dois pontos finais a caminhos NAT redundantes e aplicações multiponto, como compartilhamento de documentos. O texto diz que a complexidade da coordenação cresce geometricamente com o número de pontos finais.

Não fornece equação nem curva de custo medida: descreve um problema de escala arquitetural, não um resultado experimental.

A redundância acrescentava outra dependência de estado. Dois tradutores em caminhos alternativos precisavam manter uma visão consistente dos mapeamentos de um dispositivo. Se o estado da conexão permanecesse em um caminho e o tráfego migrasse para outro, a nova rota poderia criar um mapeamento diferente. Voltar ao caminho original não garantiria a recuperação da conversa. O endereço dentro do pacote não era todo o estado; também importavam o mapeamento do tradutor e sua posição no caminho.

O custo podia mudar de organização. A RFC 2993 observou que um NAT gerenciado pelo provedor poderia reduzir parte da carga de suporte do ISP e, ao mesmo tempo, ampliar o trabalho local de administração de endereços e nomes. É uma transferência de carga descrita no documento, não uma medição de aumento universal do custo total. Depois de uma fusão, por exemplo, a equipe local poderia ter de resolver endereços privados duplicados, organizar respostas DNS diferentes para dentro e fora ou coordenar uma correção de aplicativo que antes não era visível ao provedor.

A segurança tornava mais importante distinguir tradução de política. A RFC alerta que o NAT — sobretudo a tradução de portas — pode dar a impressão de uma barreira de segurança sem a intenção explícita de controle de acesso de um firewall. O documento também discute problemas de compatibilidade com IPsec, comportamento do DNS e autenticação SNMPv3. São mecanismos dependentes de protocolo e configuração, não prova de que todo NAT inviabiliza qualquer protocolo de segurança. O tradutor altera evidências que dependem do endereço; sozinho, não decide qual tráfego deve ser permitido.

O registro posterior tornou o trabalho mais explícito, mas não prova que tenha desaparecido. A RFC 3022 substituiu a RFC 1631 em 2001 com uma descrição do NAT tradicional. A RFC 3235 publicou orientações para projetistas de aplicações compatíveis com NAT em 2002. Esses textos não provam que a RFC 2993 tenha causado uma implantação específica nem que todos os programas tenham seguido suas orientações. Eles mostram como uma técnica de borda passou a ter uma literatura de projeto de aplicações ao seu redor.

A contribuição histórica da RFC 2993 não é um veredito de que todo NAT falha. É separar a economia de endereços na borda do trabalho de compatibilidade necessário nas camadas acima. O tradutor podia ficar em um só gateway; o reparo talvez exigisse atualizar aplicações em muitos pontos finais, manter estado coerente por vários caminhos e administrar nomes localmente. A rede não fez o trabalho sumir: mudou quem precisava percebê-lo e coordená-lo.

Fontes