O endereço Internet Protocol (IP) leva o pacote de uma rede para outra; o endereço Media Access Control (MAC) leva o frame (quadro) até o equipamento vizinho, dentro da mesma rede local. O Address Resolution Protocol () é o mecanismo, pequeno e antigo, que liga um endereço ao outro, e a prova de fundamentos da F5, hoje aposentada, cobrava três habilidades sobre ele: dizer que serviço o ARP presta, confirmar, pela saída do ARP, que a resolução funcionou e explicar o MAC masquerading. As três continuam sendo usadas todos os dias.

A primeira metade de todo endereço de hardware é um prefixo registrado; o que é um OUI explica quem atribui esse prefixo e o que ele revela sobre um equipamento que você nunca viu.

Para que serve o ARP

Quando um host precisa enviar um pacote para um IP da própria sub-rede, ele manda um broadcast perguntando quem tem aquele IP, e o dono do endereço responde com o seu MAC. Quem perguntou guarda a resposta na tabela ARP, que é um mapeamento um para um entre IP e MAC: cada entrada expira depois de algum tempo e é renovada quando volta a ser necessária. Para destinos fora da sub-rede, o host nem tenta descobrir o MAC do destino: ele faz ARP para o default gateway e entrega o pacote ao gateway. É por isso que um gateway configurado errado aparece como uma entrada ARP apontando para o roteador errado, e não como uma mensagem de erro de roteamento.

O protocolo está na 826, "An Address Resolution Protocol", escrita por David C. Plummer em novembro de 1982 (RFC 826). O pacote ARP é curto, e todos os campos dele continuam em uso; os valores vêm dos registros da (IANA, parâmetros do ARP; IANA, EtherTypes):

Campo (RFC 826)TamanhoPara IPv4 sobre Ethernet
ar$hrd, espaço de endereços de hardware16 bits1, que a IANA ainda lista como "Ethernet (10Mb)"
ar$pro, espaço de endereços de protocolo16 bits0x0800, IPv4
ar$hln, ar$pln, o tamanho de cada um dos dois endereços8 bits cada6 e 4
ar$op, o opcode (código da operação)16 bits1 "REQUEST" ou 2 "REPLY"
ar$sha, ar$spa6 e 4 octetoso MAC e o IP do remetente (sender)
ar$tha, ar$tpa6 e 4 octetoso MAC e o IP do alvo (target); num request, o MAC é justamente o que se quer descobrir

O ARP vai direto dentro do frame Ethernet, com um próprio, o 0x0806, registrado na lista da IANA como "Address Resolution Protocol (ARP)". Uma regra da RFC 826 explica boa parte do que vem a seguir. Quem recebe um pacote ARP verifica primeiro se já conhece o remetente, antes mesmo de olhar o opcode: "If the pair <protocol type, sender protocol address> is already in my translation table, update the sender hardware address field of the entry with the new information in the packet". A especificação de requisitos para hosts põe um limite nisso: "A mechanism to prevent ARP flooding (repeatedly sending an ARP Request for the same IP address, at a high rate) MUST be included. The recommended maximum rate is 1 per second per destination" (RFC 1122, seção 2.3.2.1).

O endereço MAC em si tem 48 bits, escritos como seis pares hexadecimais; a primeira metade é o Organizationally Unique Identifier () do fabricante, e a segunda identifica o equipamento. Um MAC válido é um MAC bem formado e, num segmento real, único: ter dois equipamentos com o mesmo MAC é uma falha bem particular, e bem feia.

Como provar que a resolução funcionou

Na saída de um comando ARP, ou num diagrama, a resolução funcionou se o IP de destino aparece com um MAC resolvido, ou seja, numa entrada completa. Se a entrada está incompleta, ou se o IP nem aparece depois de uma tentativa de tráfego, a pergunta foi feita e ninguém respondeu: sub-rede errada, host fora do ar ou uma que, na prática, não chega até o host. Esse é o ponto de verificação da camada 2 em qualquer troubleshooting de conectividade feito passo a passo: antes de culpar o roteamento ou os firewalls, confirme que a entrada ARP do next hop (o próximo salto do caminho) está completa. Num BIG-IP, a mesma verificação vale para o que o equipamento enxerga dos pool members e dos gateways.

Os comandos mudam de um sistema para outro; a leitura, não. No Windows, o arp -a "Displays the current ARP entries by querying the protocol data" (Microsoft Learn, arp). No Linux, o ip neigh mostra cada entrada com o seu estado (ip-neighbour(8)): reachable, "valid until the reachability timeout expires"; stale, "valid but suspicious", que será conferida na próxima vez que for usada; incomplete, "has not (yet) been validated/resolved"; e failed, "max number of probes exceeded without success". Uma entrada failed para o gateway mostra que o problema está na camada 2, por mais que a pergunta parecesse ser de roteamento.

Gratuitous ARP: o host anuncia o próprio endereço

O é um anúncio não solicitado: o host manda em broadcast o próprio mapeamento entre IP e MAC, sem que ninguém tenha perguntado. A função dele é corrigir os caches, e quem faz isso funcionar é a regra de merge da RFC 826 (a que atualiza uma entrada já existente): todo mundo no segmento que já tem uma entrada para aquele endereço atualiza essa entrada na hora. É esse mecanismo que permite mover um endereço IP: quando um endereço flutuante (floating) passa de um equipamento para outro durante um failover, o novo dono envia gratuitous ARPs para que os switches e os vizinhos passem a encaminhar o tráfego para a nova porta, e não mais para a antiga.

Mais tarde, a RFC 5227 deu nomes precisos a esses pacotes (RFC 5227, julho de 2008). O ARP Probe é "an ARP Request packet, broadcast on the local link, with an all-zero 'sender IP address'", enviado para verificar se um endereço está livre antes de usá-lo; o ARP Announcement é o mesmo pacote, "except that both the sender and target IP address fields contain the IP address being announced". Sobre o nome antigo, a RFC é direta: "What Stevens describes as Gratuitous ARP is the exact same packet that this document refers to by the more descriptive term 'ARP Announcement.'"

Proxy ARP: o roteador responde por outro host

Um roteador também pode responder no lugar de hosts que não estão no segmento. A RFC 1027, de outubro de 1987, descreve esse truque, pensado para hosts que não entendiam sub-redes: "The gateway can then respond for host B, saying that the network address for host B is that of the gateway itself. Host A will see this reply, cache it, and send future IP packets for host B to the gateway" (RFC 1027). Isso ainda aparece por aí: se a tabela ARP mostra o MAC do roteador para um endereço IP que não é do roteador, é o proxy ARP em ação.

Nada no pacote prova quem o enviou

Olhe a tabela de novo: não há nenhum campo que sirva de prova. Qualquer host pode responder a qualquer request, ou anunciar qualquer mapeamento sem ninguém perguntar, e, por causa da regra de merge, os vizinhos acreditam. O (envenenamento do cache ARP) é só isso. É o exemplo clássico das formas de desviar tráfego, e é por ele que começa a série sobre desvio de tráfego, junto com os recursos de switch que acabam com ele.

MAC masquerading: o endereço muda de lugar sem mudar de MAC

O gratuitous ARP atualiza os vizinhos, mas alguns ambientes demoram a reagir ou filtram essas atualizações. O MAC masquerading elimina o problema: o traffic group flutuante tem um endereço MAC próprio, que a referência de comandos da F5 descreve como a opção mac do traffic group, "Specifies a MAC address for the traffic group" (referência tmsh da F5, cm traffic-group). Depois de um failover, o mapeamento entre IP e MAC não muda em nada: o mesmo MAC simplesmente aparece em outra porta do switch, e os switches aprendem a porta nova já no primeiro frame. Os caches ARP dos vizinhos continuam válidos, porque nada do que eles guardaram mudou. O blueprint da prova aposentada pedia ao candidato que explicasse para que serve o MAC masquerading, e a resposta cabe numa frase: tornar invisível, na camada 2, a migração de um endereço, para que a velocidade do failover deixe de depender da rapidez com que todos os outros atualizam as suas tabelas.

O IPv6 não tem ARP

No IPv6, quem resolve endereços é o Neighbor Discovery, e a RFC 4861 diz o que ele substituiu: "The IPv6 corresponds to a combination of the IPv4 protocols Address Resolution Protocol, Router Discovery, and ICMP Redirect" (RFC 4861, setembro de 2007). O Neighbor Discovery mantém um cache de vizinhos (neighbor cache) com os mesmos estados que o Linux mostra para o ARP (incomplete, reachable, stale, delay e probe), então a leitura que vimos acima vale também ali.

Fontes