Resumo

  • A RFC 875 separou o gateway que encaminhava um datagrama IP comum do tradutor que precisava conciliar endereços, confirmações, fluxo e opções com significados incompatíveis.
  • Quando o intermediário encerrava dois protocolos e guardava a correspondência entre eles, tornava-se o ponto singular da sessão, da redundância e das futuras mudanças.

Um desenho de rede costuma conceder ao retângulo central uma capacidade extraordinária. De um lado entra uma conexão NCP; do outro sai TCP/IP; entre elas há uma seta limpa. O desenho não mostra quem inventou o destino que não cabia no endereço de origem, nem quem decidiu que uma confirmação local valia como entrega remota.

M. A. Padlipsky dedicou a RFC 875, Gateways, Architectures, and Heffalumps, a abrir esse retângulo. Publicado em setembro de 1982, o memorando não era um padrão de implementação e não fazia um levantamento de tradutores em produção. Sua alegação era arquitetural: ligar conjuntos incompatíveis por tradução não era apenas ampliar a função de um gateway Internet.

O gateway estreito preservava um acordo amplo o bastante

A RFC 791 definiu o datagrama IP como o objeto comum entre redes de pacotes. Endereços Internet e fragmentação permitiam atravessar tecnologias locais diferentes. Confiabilidade, ordenação e controle de fluxo fim a fim não faziam parte da promessa de IP.

Essa exclusão mantinha o limite inteligível. Um gateway removia o enquadramento da rede de entrada, escolhia o próximo salto e colocava o mesmo datagrama no enquadramento da saída. Não precisava assumir a identidade dos hosts TCP. A própria RFC 791 dizia que os protocolos de nível superior não precisavam ser implementados no gateway.

A RFC 793 atribuía ao TCP nos hosts as conexões, sequências, janelas, retransmissões e indicações urgentes. A arquitetura não evitava complexidade; distribuía cada promessa para um lugar em que pudesse ser observada.

Portanto, RFC 875 não argumentava contra redes heterogêneas. IP já havia sido desenhado para elas. Padlipsky distinguia a adaptação local sob um objeto compartilhado da incompatibilidade semântica, situação em que o objeto de um lado não tinha equivalente determinado no outro.

Um endereço não ganhava outra rede por conversão de formato

NCP nomeava um host dentro do espaço ARPANET. O endereço IP incluía rede e host. A interface NCP comum não oferecia uma posição para o usuário dizer que queria um host localizado em outra rede.

Era possível aproveitar bits, alterar o protocolo inicial ou inserir um endereço Internet nos dados da aplicação. Cada expediente mudava o lado NCP que a tradução pretendia preservar. A lacuna não era tipográfica: faltava no contrato uma dimensão inteira do destino.

RFC 875 descreveu uma saída deliberadamente visível. O intermediário podia agir como host, encerrar a primeira conexão, perguntar ao usuário qual sistema estrangeiro desejava e iniciar uma segunda. Padlipsky chamou a solução de “Janus Host”. Ela podia funcionar para interação por Telnet, mas era um relay, não uma continuação transparente.

A RFC 801 materializou esse tipo de transição. Em Telnet, o usuário entrava num host de relay por uma conta especial e abria outra sessão. Em FTP, o arquivo passava por dois movimentos. O correio tinha sua própria operação. Cada aplicação assumia a custódia entre duas pernas em vez de delegar a uma tradução universal.

O buffer guardava dados, não criava evidência

No NCP, um Ready for Next Message vinha do IMP de destino. Quando havia um tradutor, esse IMP podia ser o equipamento ao lado do gateway, e não o host final do outro conjunto. A confirmação respondia a uma fronteira diferente.

O tradutor poderia segurá-la e acumular bytes. Faltava, porém, definir o evento remoto que liberaria o envio: a rede aceitou o pacote, o transporte o recebeu ou a aplicação o consumiu? Se o protocolo estrangeiro não publicava o fato necessário, mais memória apenas adiava a escolha.

Controle de fluxo não é só taxa. Ele identifica a parte que deve parar, o recurso protegido e a prova para recomeçar. Quando dois protocolos escolhem limites diferentes, o gateway passa a carregar a incompatibilidade como estado. Seu buffer pode se tornar a maior fila do caminho e ainda assim não saber se o receptor final está pronto.

Sinais excepcionais podiam ordenar ações distintas

O NCP tinha um comando de interrupção num enlace de controle. TCP oferecia o mecanismo Urgent; Telnet acrescentava Interrupt Process; outras famílias falavam em dados expeditos. Os nomes convidavam a uma tabela de equivalência, mas a pergunta era qual componente deveria agir.

Pela RFC 793, a indicação urgente estimulava o usuário receptor a processar dados urgentes e acompanhava as transições desse modo. Dar prioridade ao interpretador de protocolo não é necessariamente mandar o processo de destino interromper seu trabalho.

O tradutor não dispunha de uma conversão neutra. Descartar perdia funcionalidade. Tratar entrega expedita como interrupção de processo inventava autoridade. Terminar a aplicação e executar uma política própria reconhecia que o gateway estava tomando a decisão.

Padlipsky relatou de forma limitada uma experiência do University College London: um gateway de terminal entre Telnet da ARPANET e X.25/X.28/X.29 conseguia transportar dados, mas apenas a opção de eco atravessava. A RFC 875 não oferece uma auditoria completa desse sistema. O exemplo basta para separar duas provas: caracteres visíveis e preservação das opções que governam esses caracteres.

O estado transformava uma caixa em ponto singular

Para realizar todas as correspondências, o gateway manteria dois identificadores de conexão, dois espaços de sequência, estados de fluxo, associações de endereço, opções e pressupostos de aplicação. Colocar uma segunda máquina ao lado não transferia esse conjunto vivo.

RFC 875 chamou a condição de ponto de singularidade. O roteamento de pacotes podia contornar um enlace, mas não recriava a conversa privada guardada pelo tradutor. Uma redundância verdadeira exigia replicação de estado, resolução de conflito e protocolo de tomada de controle. O retângulo deixava de ser uma função e se tornava um sistema distribuído.

O mesmo acoplamento se acumulava nas versões. Um tradutor A–B não atendia A–C. Uma mudança em A ou B exigia revisar as caixas correspondentes. O intermediário importava para si o calendário e as ambiguidades dos dois lados.

Um roteador posterior continuava fazendo adaptações reais

A RFC 1009 definiu depois o gateway Internet como roteador no nível IP. Ele tratava enquadramento, MTU, mapeamento de endereço local, sinais locais de fluxo ou erro, buffers e escolha de rota. Ser “estreito” não significava ser simples.

O que permanecia estreito era o compromisso: entre as adaptações havia o mesmo datagrama IP. O roteador não precisava reconstruir a confirmação da aplicação distante ou transformar uma ação excepcional dirigida a um protocolo em comando para outro processo.

A história posterior recolocou o teste em outros sistemas

A RFC 2775 apontou que tradução de endereços quebra a transparência fim a fim. Aplicações que levam endereços no payload passam a exigir gateways de aplicação ou proxies; uma aplicação nova pode demandar conhecimento novo no intermediário.

A RFC 3234 descreveu middleboxes e reconheceu seus usos, ao mesmo tempo em que registrou falhas próprias: desvio para uma caixa sem o estado anterior, queda de sessões no reinício e diagnóstico cruzando várias camadas. O gateway de aplicação mantém estado porque participa da semântica da aplicação.

A RFC 4966 moveu NAT-PT para Historic por problemas específicos, entre eles endereços embutidos, diferenças IPv4/IPv6, fragmentos, vida dos mapeamentos, escala do DNS-ALG e concentração de falha ou ataque. Esses documentos não provam que toda tradução fracassa e não são uma linha causal direta da RFC 875. Eles repetem a exigência: explicar a semântica e o estado, não só a troca dos cabeçalhos.

O significado ausente precisava de um autor

Cada seta que cruza um intermediário pode ser auditada com quatro perguntas: qual afirmação entrou, qual saiu, quem decidiu que eram equivalentes e qual evidência permite confirmar a decisão após uma falha.

Se há um protocolo comum mínimo, o gateway preserva um objeto determinístico enquanto adapta o contexto local. Sem ele, as escolhas são assumir a interseção dos serviços, terminar e recomeçar, adicionar semântica a uma ponta ou aceitar a perda de uma função.

Nenhuma dessas escolhas é “apenas tradução”. Bytes recebidos, endereço reescrito e eco funcionando são fatos úteis, mas não comprovam confirmação fim a fim, identidade de urgência, opções preservadas ou continuidade da sessão. O gateway consegue levar aquilo que ambos os lados especificaram. A garantia inexistente precisa ser recusada ou criada por uma autoridade visível.

Fontes