Resumo

  • O RFC 1868 tratou do intervalo em que um host discado voltava por um segundo servidor de comunicações, enquanto vizinhos da LAN ainda mantinham no cache o endereço físico do primeiro servidor aprendido por Proxy ARP.
  • UNARP reutilizava uma resposta ARP não solicitada com comprimento de endereço de hardware igual a zero. Receptores compatíveis deveriam excluir a entrada da IP de origem; pilhas sem suporte deveriam rejeitar o formato abreviado.
  • Transmitir o broadcast, recebê-lo, aceitar sua sintaxe, apagar uma entrada local, aprender o novo proxy e encaminhar dados com sucesso eram fatos separados. O pacote não confirmava os estágios posteriores.

A sessão mudou; a lembrança local não

Considere um usuário remoto que entra por CS1 em um conjunto compartilhado de modems. Para Host A, na rede local, o endereço IP do usuário parece vizinho, embora o computador esteja atrás do servidor de comunicações. Quando Host A pergunta via ARP, CS1 responde em nome do remoto e informa seu próprio endereço de hardware. Host A armazena essa resposta e envia os quadros seguintes a CS1.

Esse era o acordo de compatibilidade do Proxy ARP documentado no RFC 1027. O gateway escondia a sub-rede e poupava os hosts de entender uma nova rota. Em troca, a realidade do caminho ficava comprimida em uma associação local entre o IP do usuário e o hardware do intermediário.

O usuário desliga e retorna por CS2 antes de o cache de Host A expirar. O IP permanece. O intermediário correto mudou. Host A continua remetendo a CS1 porque sua tabela conserva uma informação que ainda é válida como sequência de bits, mas deixou de ser válida como descrição do acesso.

ARP não tinha uma comissão central de memória

O RFC 826 definiu ARP para distribuir associações entre endereços de protocolo e de hardware. Um Request pergunta por um alvo; um Reply oferece um mapeamento do emissor que o receptor pode incorporar à sua tabela e reutilizar.

Cada host mantém essa tabela para si. Não há uma transação na qual todas as máquinas confirmem uma versão comum. Essa escolha torna a resolução próxima de quem precisa dela, mas permite que vizinhos diferentes carreguem lembranças com idades diferentes depois de uma mudança.

O RFC 1122 exigiu algum mecanismo para invalidar entradas antigas e enumerou quatro possibilidades combináveis: expiração, consulta unicast, aviso da camada de enlace e aviso de uma camada superior após problema de entrega. Cada uma revela algo próprio. Um timer mede política local; uma sondagem sem resposta mede silêncio; um aviso de enlace mede uma falha próxima; uma indicação superior mede uma consequência vista em outra camada. Nenhuma delas, isoladamente, declara que o usuário reapareceu em CS2.

Um Reply sem resposta de hardware

Publicado como Experimental em novembro de 1995, o RFC 1868 acrescentou uma afirmação negativa ao repertório. UNARP usava o opcode 2 de ARP Reply, o tipo de protocolo IPv4 e comprimento de protocolo quatro, mas fixava em zero o comprimento de hardware. O IP do host que saía ocupava o endereço de protocolo de origem; 255.255.255.255 era o destino. Sem os dois campos de hardware, restavam dezesseis bytes antes do cabeçalho de enlace.

Uma implementação compatível deveria excluir do cache a entrada indexada por aquele IP. O servidor não precisava guardar se havia anteriormente emitido o Proxy ARP Reply: podia enviar UNARP em toda desconexão. Um host que deixasse uma LAN de modo ordenado também poderia transmitir o aviso por conta própria.

A assimetria favorecia o esquecimento. Uma exclusão desnecessária custaria uma nova resolução. A permanência de uma entrada errada continuaria desviando quadros ao servidor antigo. O protocolo preferiu reabrir a pergunta a sustentar uma resposta vencida.

Mesmo assim, uma exclusão não instalava o novo caminho. Host A ainda precisava emitir outro Request, receber um Reply, aprender o hardware de CS2 e testar o encaminhamento. Apagar CS1 não era comprovar CS2.

Conviver com pilhas antigas preservava mais de um silêncio

O comprimento zero funcionava como discriminador de compatibilidade. Uma máquina que conhecesse RFC 1868 entenderia a exclusão. Uma implementação tradicional deveria rejeitar o Reply curto como inválido, em vez de armazenar um endereço de hardware todo zerado. O projeto admitia desde o início que os dois comportamentos dividiriam a mesma LAN.

O texto recomendava ainda uma opção para desativar UNARP caso algum produto existente reagisse mal. Logo, a extensão podia estar implementada e mesmo assim desligada. A publicação do RFC descrevia uma mensagem possível, sem transformar toda pilha instalada em participante.

Para CS1, a ausência de resposta não diferenciava quem recebeu e apagou, quem recebeu e recusou, quem perdeu o quadro, quem desligou o recurso ou quem não possuía a entrada. Não havia uma relação de confirmações. A expectativa de suporte amplo registrada no documento era uma expectativa, não um levantamento operacional.

MAPOS repetiu a mensagem e tornou a exclusão condicional

O RFC 2176 definiu em 1997 um UNARP relacionado para IPv4 sobre MAPOS. A variante ganhou opcode próprio e campos de hardware reais. Quando uma porta subia, o nó enviava três broadcasts com intervalos de trinta segundos. O receptor só removia o mapeamento IP quando o hardware anunciado diferia do valor já guardado.

Três tentativas reduziam o risco de um único quadro perdido. A comparação evitava apagar um mapeamento já coerente com o nó que se apresentava. Ainda assim, três transmissões não eram três recibos. O RFC exigia separadamente envelhecimento de cache e limpeza imediata na perda do enlace. A confiabilidade permanecia apoiada em controles diferentes.

O RFC 3790 classificou depois RFC 1868 como extensão dependente de IPv4 para excluir entradas ARP. A classificação fixa sua finalidade no registro documental; não mede implantação, conformidade ou sucesso.

A declaração positiva também não encerrava o serviço

O RFC 5227 explicou mais tarde que um ARP Request carrega ao mesmo tempo uma afirmação nos campos do emissor e uma pergunta nos campos do alvo. Um Probe pergunta se o endereço está em uso enquanto indica intenção de reivindicá-lo. Um Announcement afirma que o emissor passou a usá-lo.

UNARP fazia o movimento contrário: abandonem a associação anterior. Ambas as mensagens são entradas locais, avaliadas pela sintaxe, política e estado de cada receptor. Nenhuma demonstra acordo universal, ausência de conflito, entrega do próximo quadro ou resultado da aplicação.

O ponto histórico não é que ARP deveria ter adotado um árbitro central. É que um sistema distribuído precisa nomear o alcance de cada registro. “Aviso transmitido”, “quadro visto neste ponto”, “entrada apagada neste host”, “novo mapeamento aprendido” e “dados entregues” podem ser verificados separadamente. “A rede esqueceu” não cabe no recibo de quem apenas falou.

Fontes e limites

Os RFCs 826, 1027 e 1122 fundamentam ARP, Proxy ARP e invalidação de cache. RFC 1868 especifica o aviso experimental; RFC 2176 oferece uma variante posterior; RFC 3790 registra a dependência de IPv4; RFC 5227 esclarece probes e anúncios. Essas fontes comprovam formatos, regras e expectativas escritas. Não comprovam uso atual, suporte universal, conformidade de produto, incidente ou ataque real, nem entrega bem-sucedida em uma rede específica.