Resumo

  • A RFC 831, de dezembro de 1982, era uma proposta para discussão, não um padrão nem um relato de implantação. Ela examinava como manter acesso de software ao lado europeu da SATNET durante uma partição.
  • Um host multihomed chamado Munger trataria a rota de origem e reescreveria os cabeçalhos nos dois sentidos. Mesmo executando um algoritmo de gateway, permaneceria host e não emitiria atualizações de roteamento.
  • Se o equipamento remoto não soubesse criar a rota de retorno, M aprenderia uma correspondência chamada “soft state”. O texto não definiu autenticação, prazo, remoção ou auditoria, e a ambiguidade permitia apenas um host dos Estados Unidos por destino SATNET.

A infraestrutura cobrava antes que o IP pudesse ajudar

A contingência imaginada por Robert Braden na RFC 831 começava com uma rede de satélite dividida. O host de controle H, nos Estados Unidos, normalmente passava pelo gateway B da BBN, pelo SIMP S1, pela SATNET, pelo SIMP S2 e pelo gateway G da University College London. Com a partição, os gateways americanos já não tinham uma rota normal para S2, G ou o controlador de acesso de terminais da UCL. Um datagrama comum seria descartado, possivelmente com ICMP Unreachable.

Do lado britânico, H também ficava inalcançável. Portanto, introduzir uma solicitação perto de S2 resolvia apenas metade do problema. A resposta comum continuaria apontando para uma origem sem rota.

O caminho alternativo saía de H, alcançava o gateway VAN, atravessava um túnel IP da VANNET, entrava na UCL, seguia por UCLNET até G e S2. Código especial poderia existir em H e/ou no terminal britânico do túnel, sem exigir mudanças em G, S2 ou no gateway VAN. O mecanismo excepcional ficava concentrado em quem aceitava executá-lo.

O documento chamava o acesso de “back door”, mas advertia que a proposta não pretendia ser um padrão naquele momento. Não há base para dizer que ela foi implantada ou usada em uma pane real. O valor histórico está no desenho e nos limites declarados.

O endpoint não podia ensinar uma rota geral

O endpoint normal U precisava continuar sendo host. Se virasse gateway, o gateway VAN poderia aprender por ele uma rota para UCLNET. Com isso, tráfego rotineiro da UCL ou de RSRE que deveria usar SATNET poderia migrar para o túnel de contingência. Uma necessidade de manutenção alteraria o caminho de terceiros.

Para evitar isso, a RFC introduziu o Header Munger, M. Ele aparecia como M2 na VANNET e como M1 na UCLNET. M teria o algoritmo usado por um gateway para processar source routing, mas, fora dessa função, agiria como dois hosts e não enviaria atualização de roteamento.

Essa abstinência definia o escopo. Processar um pacote selecionado é uma capacidade local. Anunciar alcançabilidade pede que outros sistemas entreguem uma classe inteira de tráfego. A urgência autorizava a primeira ação, não a segunda.

Um endpoint de recuperação é seguro apenas se seu poder técnico não for confundido com mandato de trânsito. Na RFC 831, não anunciar era parte positiva da função, não uma ausência acidental de configuração.

Um pacote recebia dois novos pares de extremidades

H conseguia chegar a M2 e encaminhava a solicitação de manutenção até ali. M trocava o endereço de origem por M1 e o destino por S2 antes de enviar o datagrama a UCLNET. Para o lado europeu, as duas extremidades aparentes voltavam a ser alcançáveis.

A resposta de S2 chegava a M1. M a convertia novamente em um pacote capaz de percorrer VANNET e Internet até H. Cada reescrita corrigia uma ruptura diferente. Alterar apenas o destino não criaria retorno para H; alterar somente a origem não levaria a solicitação ao destino isolado.

Essa transformação afetava o que os sistemas podiam provar. Logs perto de S2 podiam registrar M1 em vez de H. Equipamentos do outro lado podiam conhecer M2 sem saber qual endereço o alvo observou. Receber a resposta demonstrava funcionamento de uma cadeia específica, mas não autenticava o operador, não autorizava a intervenção e não confirmava que a manutenção produziu o resultado correto.

A comparação com tradução de endereços deve ser controlada. Muito depois, a RFC 3022 descreveu mapeamentos estáticos e dinâmicos e a troca entre significado fim a fim do endereço IP e estado na rede. Isso ajuda a examinar o custo do Munger. Não torna a RFC 831 uma NAT, nem prova que ela inventou ou gerou diretamente a tecnologia.

Três saídas para uma resposta antiga

A primeira alternativa era uma correspondência fixa. M responderia por vários endereços M1/M2, associados antecipadamente a pares de origem americana e alvo SATNET. O retorno era previsível, ao preço de planejamento e ocupação de endereços para cada par.

A segunda usava source routing nas duas direções. A RFC 791 definiu Loose e Strict Source and Record Route. O emissor listava pontos intermediários; quando um deles era alcançado, o próximo substituía o destino IP e o endereço da interface corrente entrava no registro. Um destinatário capaz de inverter a lista podia construir a volta.

G entendia source routing, mas S2 e o controlador de terminais talvez não conseguissem inverter o caminho registrado. A alternativa preferida era híbrida. H colocava o desvio na solicitação. Ao processá-la, M aprendia uma relação entre o host americano e o alvo SATNET. Uma resposta normal, endereçada a M1, podia usar essa relação para retornar a H.

A RFC 831 chamou a correspondência de “soft state”. O rótulo não deve ganhar propriedades que o texto não especificou. Não há intervalo de atualização, temporizador de expiração, regra de exclusão, recuperação após reinício ou trilha de auditoria. Também não se descreve autenticação para criar a entrada.

O estado perdia um discriminador. Apenas um host americano por vez podia acessar determinado host SATNET. Se duas origens compartilhassem o alvo, a resposta sem rota de retorno não forneceria a M informação suficiente para escolher H. A restrição era evidência da ambiguidade da chave, não uma meta de escala.

Uma linha PSS exigia endereços mais longos

O túnel VANNET usava um serviço X.25 comutado em que o chamador arcava com as tarifas. No funcionamento normal, a UCL iniciava o túnel a partir de U. Para chegar a M2, a ponta americana iniciaria a chamada. A direção definia quem precisava estar operacional e quem pagaria.

Havia uma única linha física PSS na UCL. Para que U e M compartilhassem essa linha, eram necessárias subendereços X.25 distintos. O gateway VAN também teria de aceitar endereços X.121 de quatorze dígitos, além dos de doze. Uma diferença de dois dígitos no serviço inferior podia bloquear uma solução IP completa no papel.

O ponto não é transformar tarifas de X.25 em explicação geral da Internet. É registrar que um runbook de contingência precisa incluir o iniciador, a linha, o formato do endereço, a capacidade do equipamento e a conta. O diagrama lógico não estabelece uma chamada sozinho.

O ato de encaminhar trazia deveres de gateway

Mais tarde, a RFC 1122 permitiu a um host agir como salto intermediário de uma rota de origem, mas exigiu regras semelhantes às de gateway para TTL, erros ICMP e opções. Encaminhar a um destino não local deveria depender de um controle configurável, desativado por padrão, e de filtros de política.

Isso torna explícito o papel de M. O programa podia viver em um host; ao executar um salto intermediário, assumia efeitos de roteamento. O nome da máquina não eliminava as obrigações do processamento.

A mudança operacional foi gradual. Em 1995, a RFC 1812 ainda exigia suporte dos roteadores às opções de rota de origem em pacotes encaminhados e descrevia um controle de descarte que não ficava habilitado por padrão. É um retrato histórico, não recomendação atual.

A RFC 6274 mais tarde avaliou que riscos como contornar firewall, alcançar máquinas de outro modo inacessíveis, ocultar conexões, descobrir topologia e consumir recursos superavam o valor de diagnóstico. Recomendou descarte por padrão. A RFC 7126 observou que a filtragem disseminada tornara LSRR quase impraticável para troubleshooting e propôs controle documentado por opção, com descarte como postura normal.

Logo, a publicação de uma opção não garantia trânsito. A contingência dependia de decisões locais de operadores independentes, que podiam racionalmente recusar o processamento.

“Middlebox” descreve a ação, não a delegação

A RFC 3234 posteriormente chamou de middlebox um intermediário que faz mais que o roteamento IP comum, inclusive transformar ou desviar fluxos. Como ferramenta de análise, a definição acomoda M: ele mudava cabeçalhos, mantinha uma relação e criava novos pontos de falha. Não era a terminologia usada pela RFC 831.

O nome também não resolve as perguntas de controle. Quem podia invocar M? Que destinos eram elegíveis? Quando o estado terminava? Quem provava a limpeza? Chamá-lo simplesmente de gateway seria pior, porque poderia sugerir a autoridade geral que o texto recusou.

A descrição exata preserva a tensão: M era um host multihomed, capaz de um trabalho semelhante ao de gateway para tráfego de manutenção selecionado, sem anunciar rotas.

Alcançar o equipamento não concedia direito de mudá-lo

A RFC 831 não especificou identidade, autorização de destino, criptografia, comandos, aprovação de mudança ou confirmação de sucesso. “Back door” era o nome da passagem alternativa, não evidência de uma exploração. Ainda assim, uma passagem que cruza um limite fechado pela topologia normal cria uma superfície de controle.

Quatro veredictos devem permanecer separados: a solicitação chegou à entrada; o principal foi identificado; alvo e ação foram autorizados; a aplicação confirmou o efeito. Uma resposta reescrita por M sustenta o primeiro. Não substitui os outros.

O ensinamento mais durável da RFC 831 é sua recusa em ampliar a autoridade durante a falha. O código especial ficava localizado. O tráfego normal conservava seu caminho. A máquina de contingência não se apresentava à rede como trânsito.

A porta dos fundos continuava porta porque não se anunciava como rota.