Resumo

  • A RFC 1504 combinava o identificador de domínio e a faixa original numa identidade de túnel, enquanto o roteador receptor escolhia um número local sem conflito.
  • Se esse número retornasse por um caminho redundante sem o DI/UI, parecia uma rede real. O roteador podia remapeá-lo outra vez e criar uma shadow network: várias linhas para uma única rede física.
  • Snapshot, update, RI-Ack, linha de MIB e rota utilizável eram recibos parciais. A investigação precisava ligar época do mapeamento, porta, conexão, sequência, caminho e resultado da carga útil.

O buraco que uma atualização nova não consertava

Alan Oppenheimer, da Apple Computer, publicou a RFC 1504 em agosto de 1993 como documento informativo. O objetivo era documentar um protocolo Apple que poderia rodar sobre a Internet. As oitenta e duas páginas não o transformavam num padrão da Internet nem comprovavam qualquer implantação específica.

AURP substituía parte da repetição de RTMP e ZIP por uma troca inicial seguida de eventos. Cada conexão unidirecional tinha um ID; cada pacote tinha sequência; o emissor esperava RI-Ack antes de avançar. Se a confirmação não chegasse, retransmitia a resposta correspondente.

Mesmo assim, a visão não era atômica. Um novo peer podia começar a troca quando o emissor ainda guardava eventos pendentes. A fotografia inicial e o update seguinte podiam parecer incongruentes. A RFC ensinava o receptor a converter alguns casos: mudança de distância de rede desconhecida virava adição; adição de rede conhecida virava mudança de distância; certos eventos de baixa desconhecidos eram ignorados.

Essas regras produziam um estado utilizável a partir de observações fora de fase. Não provavam que todos os roteadores tinham a mesma tabela naquele instante.

O overflow tornava o limite explícito. Se o receptor não tivesse espaço para toda a informação, o emissor não repetiria indefinidamente cada pedaço perdido. Ao recuperar capacidade, o receptor deveria enviar RI-Req e obter a tabela completa. Uma história furada precisava de nova base; o último delta não bastava.

A numeração local não cabia no túnel compartilhado

O túnel podia juntar internets AppleTalk administradas de forma independente. Duas organizações podiam ter escolhido legitimamente o mesmo número de rede. O conflito só aparecia quando as duas passaram a compartilhar um domínio de encaminhamento.

AURP separava a identidade usada no túnel da apresentação usada no local. A rede exportada recebia um UI. Num roteador com remapeamento, o UI combinava o DI exclusivo do domínio com o número ou a faixa original. No lado receptor, o roteador associava essa identidade a um número livre de uma faixa reservada.

Os nós antigos continuavam enxergando números AppleTalk comuns. Não precisavam aprender uma nova arquitetura de identidade. A fronteira fazia a tradução e guardava a relação.

Porém, o número local não carregava sua própria origem. O mesmo UI podia ganhar aliases diferentes em dois domínios. O mesmo alias podia apontar para UIs diferentes em épocas diferentes. “Número igual” e “número diferente” eram conclusões fracas sobre o objeto real.

Estático preservava correlação; dinâmico aumentava capacidade

O remapeamento estático reservava um número conhecido para determinado UI. A operação e a auditoria ficavam simples, mas o estoque acabava. O dinâmico distribuía números conforme redes surgiam, aproveitando melhor a faixa e introduzindo reutilização.

A RFC 1504 recomendava reusar somente depois de esgotar as outras opções e não entregar imediatamente o lugar de uma rede que caiu a uma nova rede. A ausência na tabela corrente não apagava pacotes atrasados, caches, relatórios ou outra conexão.

Por isso, o registro útil precisava incluir roteador, porta, DI, faixa original, alias local, época, horário de criação e retirada. Sem época, um número reaproveitado podia transformar tráfego antigo em ação sobre um objeto novo.

A escolha tinha economia clara. Estático gastava números para comprar memória estável. Dinâmico economizava números e passava a dever um ledger temporal.

A tradução mexia no pacote, mas não entendia tudo

O roteador podia remapear o número na cabeça DDP, no endereço de entidade NBP e nos dados de roteamento AURP. Quando havia checksum DDP, verificava o valor antes da mudança e o zerava depois. A prova antiga não cobria o pacote reescrito.

Protocolos de terceiros podiam guardar endereços AppleTalk em lugares desconhecidos. O remapeador não tinha como encontrar todo número embutido. A cabeça chegava certa, a referência interna ficava errada. Túnel ativo e rota boa não garantiam a aplicação.

A gestão tinha outra perspectiva. Consultas através do túnel podiam devolver números originais nos dados. A estação precisava consultar também a base de remapeamento AURP para obter o alias local. A RFC 1742, posterior, padronizou objetos AppleTalk para portas, tabelas RTMP e contadores. Esses objetos ajudavam a observar; nenhum deles substituía o vínculo completo entre original, alias e efeito.

Uma tela podia mostrar o UI, outra o alias, outra o número original trazido por SNMP. As três podiam estar corretas e ainda parecer contraditórias porque escondiam sua camada.

O número local voltou pela porta errada

A shadow network surgia com redundância. As duas internets AppleTalk estavam ligadas pelo túnel e também por outro caminho. Um UI remoto era convertido num número local. Esse número circulava, atravessava o caminho secundário e voltava ao roteador que o havia criado.

Na volta, faltava o DI e a faixa original que identificavam a tradução no túnel. O número parecia uma rede local real. O roteador não conseguia perceber que via o próprio resultado e o exportava como uma rede nova, criando outro UI ou outro alias.

Agora duas faixas descreviam uma só rede física. Outra volta criava mais uma. A RFC 1504 chamou essas representações de shadow networks. A multiplicação seguia até a distância aparente ultrapassar o limite de hops.

O limite evitava movimento sem fim, mas não recuperava provenance. Eliminar uma rota por distância não dizia qual linha era a rede e qual era o espelho.

Um túnel multiponto assumia mais do que conseguia observar

AURP fazia um túnel multiponto parecer um único enlace virtual. Cada exterior router aplicava split horizon: anunciava sua internet local e não devolvia pelo mesmo túnel o que aprendera de outro exterior router.

A regra supunha que todos os participantes se comunicavam diretamente. Um túnel parcialmente conectado podia ser política deliberada ou erro. O roteador geralmente não conseguia diferenciar. B podia falar com A e C, enquanto A e C não se viam; ainda assim, a abstração dizia que os três estavam no mesmo enlace.

Em certos casos, duas definições independentes de túnel expressavam melhor a realidade e permitiam que B encaminhasse entre A e C. A lição não é abolir abstrações. É não tratar o nome da abstração como observação de conectividade.

Implantação parcial criava detecção parcial

Cada administrador habilitava remapeamento no seu roteador. Se alguns o fizessem e outros não, aumentava o risco de conflito. Também se rompia a simetria de detecção: roteadores com remapeamento executavam a verificação relacionada; os demais não.

Um loop entre dois roteadores sem remapeamento podia passar despercebido e entregar cópias a um roteador que remapeava. A tabela desse último recebia várias sombras de redes ligadas aos dois caminhos.

Roteadores redundantes que remapeavam precisavam usar o mesmo DI para a internet local e as mesmas relações UI-alias. A RFC mencionava configuração completa comum ou um futuro compartilhamento, mas dizia que AURP não oferecia então essa função. Havia alta disponibilidade de caminho sem alta disponibilidade transacional da identidade.

Suspeita de loop precisava de um pacote testemunha

Uma faixa recebida com o mesmo tamanho e a mesma lista de zones de uma exportação local era indício de loop. A semelhança não era veredito. A RFC propunha enviar um pacote AppleTalk pelo túnel e observar se ele voltava por uma porta local.

O teste adicionava caminho e tempo à evidência. “Parece com o meu” virava “esta instância que enviei retornou por aqui”. Ainda não provava intenção do administrador, permanência ou resultado de todos os serviços.

A seção de segurança mantinha limite parecido. Network hiding e device hiding eram descritos como forma fraca de segurança; preocupações gerais ficaram fora. Uma rede ausente do Chooser não estava autenticadamente ausente do mundo.

A investigação precisava remontar a cadeia

Para desmontar uma sombra, o operador precisava ligar:

  • <DI, faixa original> e peer exportador;
  • roteador, porta, alias e época do mapeamento;
  • connection ID, sequence e tipo snapshot/event;
  • porta e caminho de retorno;
  • versão da tabela e next hop escolhido;
  • probe ou payload do serviço pretendido.

Dois números diferentes podiam chegar ao mesmo original. Um número igual podia cruzar duas épocas. Uma route boa podia carregar uma referência interna não traduzida. Sem a cadeia, a automação escolheria com base justamente no campo que produziu a ambiguidade.

O que as fontes não demonstram

As fontes não informam quantas implantações AURP existiram, se um produto implementou todos os recursos, se houve incidente real de shadow network ou se o protocolo permanece em produção. A RFC preserva desenho e advertência, não execução.

A RFC 1378 descreve a negociação de AppleTalk em PPP e a possibilidade de transportar informação AURP no enlace; não prova convergência. A RFC 1742 define vocabulário de gestão; não garante base de remapeamento completa. Os textos de Lu Heng fornecem a disciplina editorial: especificação, implementação, decisão local, apresentação e efeito observado são registros distintos.

O caso histórico continua importante porque a compatibilidade funcionava. O alias era real o bastante para encaminhar. Exatamente por isso se tornava perigoso quando, sem a origem, passava a decidir quantas redes existiam.

Fontes