Resumo

  • O RFC 826 entrou em cena depois da escolha de rota: o host já sabia o próximo endereço de protocolo, porém ainda precisava descobrir o endereço de hardware utilizável no enlace selecionado.
  • O Request perguntava pelo alvo e, ao mesmo tempo, anunciava o caminho de volta ao remetente. A observação era guardada num cache local para executar os quadros seguintes sem novo broadcast.
  • Expiração, Proxy ARP e verificação de conflito revelaram que a resposta não era identidade autenticada. Ela podia ser uma promessa de encaminhamento, e até um endereço concedido por DHCP podia ser recusado pelo que o enlace mostrava.

O destino ausente depois da rota

A tabela IP determina se o pacote vai direto a um vizinho ou primeiro a um roteador. Em seguida, a interface Ethernet precisa de um endereço de 48 bits. O endereço IP do próximo salto e o endereço físico não têm de compartilhar tamanho, valor ou administração.

Publicado em novembro de 1982 por David C. Plummer, o RFC 826 criou um procedimento para essa fronteira. O módulo de resolução procura numa tabela o par tipo de protocolo/endereço de destino. Se encontra, entrega o endereço de hardware ao driver. Se não, transmite uma pergunta no segmento que o roteamento já havia escolhido.

O formato preserva as diferenças: tipo de hardware, tipo de protocolo, comprimentos, operação e endereços de remetente e alvo nos dois espaços. IPv4 sobre Ethernet se tornaria a aplicação célebre, mas o desenho não dependia de um único protocolo de rede nem de um único meio.

Isso evita confundir ARP com roteamento. Para alcançar um servidor remoto, o pacote mantém o IP do servidor e o primeiro quadro aponta para o gateway. ARP torna executável um salto local; não descobre todo o caminho e não certifica o destino final.

Uma pergunta ouvida por todos ao redor

Sem entrada no cache, o host informa seus próprios endereços, indica o IP procurado e faz broadcast. Todos no domínio local recebem; a máquina que reconhece o alvo devolve uma resposta diretamente ao solicitante.

A descoberta precisa ser pública porque o destino físico é desconhecido. A resposta já sabe para onde ir. O RFC 826 preferiu esse modelo sob demanda à publicidade periódica de tabelas inteiras, que produziria tráfego e estado inúteis para pares que nunca conversariam.

Na descrição inicial, o pacote que acionou a busca podia ser descartado. O RFC 1122, de 1989, recomendou conservar ao menos o pacote mais recente de cada destino ainda não resolvido. A fila reduz perda inicial, mas continua sendo estado de execução, não prova de identidade.

O mesmo documento exigiu controle contra ARP flooding e sugeriu no máximo uma solicitação por segundo para cada destino. Ausência de resposta pode ser ausência real, perda, suspensão ou separação do enlace. Repetição infinita só acrescenta carga.

Aprender antes de olhar o opcode

No algoritmo do RFC 826, o receptor verifica tipos, atualiza primeiro o mapeamento do remetente e só depois examina se a operação é Request ou Reply. Se já conhece o endereço de protocolo, o novo hardware substitui o antigo; se é o alvo e ainda não possui a entrada, ele a cria antes de responder.

Assim, a pergunta também transporta uma afirmação: “para voltar até mim, use este hardware”. O destinatário aprende o retorno antes da resposta. Um monitor pode observar essas relações mesmo sem participar do protocolo superior.

Substituir o antigo facilita a recuperação após troca ou movimento, porém evidencia a confiança limitada. Não há assinatura que prove quem falou. O valor recente é um indício operacional. Pode estar correto, equivocado ou forjado.

O RFC 826 mencionou aging e timeout sem padronizá-los. O RFC 1122 tornou obrigatório algum mecanismo de remoção de entradas velhas e recomendou timeout configurável. Sondagem unicast, indicação da camada de enlace e falha superior também podem servir. O cache só é sustentável porque possui saída.

Quando o gateway respondeu por outro host

O RFC 1027, de outubro de 1987, registrou o Proxy ARP usado para esconder sub-redes de sistemas que ainda não as entendiam. Na Universidade do Texas, alterar vários sistemas operacionais não era uma opção prática.

Quando A perguntava por B em outra rede física, um gateway com rota para B respondia com seu próprio endereço de hardware. A enviava quadros ao gateway, embora o pacote dentro deles continuasse destinado ao IP de B. A mesma técnica podia formar o retorno.

A compatibilidade veio ao preço de uma dependência invisível. O Reply não dizia “sou B”; dizia “aceito o quadro e encaminho a B”. Se vários proxies respondessem, o primeiro poderia ocupar o cache. Se a rota estivesse errada, a resolução local teria êxito e a entrega não.

O lease que ainda precisava de aprovação local

O RFC 2131, especificação DHCP de 1997, mantém uma última checagem no cliente. O servidor deve sondar um endereço reutilizado; depois do DHCPACK, o cliente deve testar antes de assumir o valor.

O teste usa um ARP Request com IP de remetente zero e o endereço oferecido como alvo. O host pergunta antes de afirmar, evitando instalar nos vizinhos um mapeamento que talvez tenha de abandonar. Se detectar uso, envia DHCPDECLINE e recomeça. Se não, anuncia o endereço para limpar caches antigos.

O servidor controla o pool e o lease. O enlace revela se a execução local entra em choque com outro equipamento. Uma atribuição administrativa válida e uma presença operacional incompatível podem coexistir.

Da resolução única à observação permanente

Em 2005, o RFC 3927 formalizou ARP Probes e Announcements para IPv4 link-local. O host espera aleatoriamente, envia sondas com IP de origem zero e anuncia o valor após sucesso. Limites e contadores evitam tempestades quando muitos dispositivos iniciam juntos ou um nó defeituoso contesta todas as opções.

A vigilância continua durante o uso. Dois enlaces separados podem escolher o mesmo endereço e ser unidos mais tarde. O resultado do boot não manda na topologia futura.

O RFC 5227, de 2008, generalizou IPv4 Address Conflict Detection. O Probe pergunta “alguém usa?” e sugere “quero usar”. O Announcement declara uso atual. Num conflito, o host pode desistir ou se defender uma vez; uma nova contradição dentro de DEFEND_INTERVAL normalmente exige retirada para impedir uma guerra de broadcasts.

Infraestrutura crítica pode ser configurada para nunca ceder, mas deve controlar e registrar as defesas. O papel operacional não autentica propriedade. Um atacante pode inventar conflito e causar negação de serviço; o silêncio de uma sonda também não prova ausência permanente.

O que o registro dos números ARP não controlava

O RFC 5494, de 2009, definiu regras IANA para tipos de hardware e opcodes, além de valores experimentais. Essa coordenação garante que implementações interpretem os campos de modo compatível.

Ela não decide qual máquina pode usar um IP numa LAN. Registrar a gramática de um protocolo é diferente de autenticar toda afirmação feita nessa gramática. Confundir os dois níveis transforma interoperabilidade em uma autoridade que o registro não recebeu.

A memória local que precisa esquecer

O ARP foi econômico: não construiu um mapa global, não obrigou anúncios de todas as relações e perguntou apenas quando um quadro precisava sair. Cada host manteve o conhecimento parcial de que necessitava.

Essa vantagem depende de revisão. Uma afirmação nova pode ser falsa, um proxy pode ocultar o ponto de falha e uma entrada estática pode sobreviver ao equipamento. O cabo é testemunha, não soberano. Quem aceita o cache, emite o quadro, testa novamente ou abandona o endereço continua sendo o host.

Fontes e limites da evidência

O RFC 826 define o formato e a aprendizagem; o RFC 1027, a resposta delegada; o RFC 1122, a expiração e o limite de solicitações. O RFC 2131 separa lease e teste local. Os RFCs 3927 e 5227 definem sondagem, anúncio e conflito; o RFC 5494 coordena números.

Os textos não provam uma data universal de adoção. Uma captura ARP prova apenas que uma mensagem foi observada num enlace e momento. Não prova, sozinha, identidade autenticada, propriedade, intenção ou entrega depois de um proxy.