Como um host realmente processa uma solicitação ARP transmitida a ele cujo endereço IP solicitado corresponde ao seu?

quando o host de destino está recebendo a solicitação ARP do meu host de origem, ele está atualizando seu cache ARP com as informações incorporadas na solicitação (já que o endereço MAC de origem está presente na solicitação ARP). Se sim, por que o host de destino às vezes envia outra solicitação ARP para o endereço IP do meu host de origem e descarta todas as solicitações de eco ICMP até receber uma resposta ARP de volta?

O host de destino deve atualizar sua tabela ARP quando vir uma solicitação ARP se já tiver a entrada em sua tabela ARP. Se a entrada não estiver em sua tabela ARP, então ele pode não criar uma entrada em sua tabela ARP.

Após alguma pesquisa, descobri que o host de destino não preenche seu cache ARP de solicitações ARP passivas, ou seja, de solicitações de outros hosts. Ele preenche seu cache ARP somente das respostas ARP que recebe de suas próprias solicitações.

Se o host for o alvo da solicitação ARP, ele deve atualizar sua tabela ARP, mas isso nem sempre acontece na prática. Se o host vir uma solicitação ARP de transmissão que não seja para ele, ele deve atualizar sua tabela ARP somente se já tiver a fonte em sua tabela ARP.

A implementação específica do sistema operacional determina como isso acontece, mas o RFC 892, um protocolo de resolução de endereços Ethernet, tem pseudocódigo para explicar o processo de recepção de pacotes.

Packet Reception:
-----------------

When an address resolution packet is received, the receiving
Ethernet module gives the packet to the Address Resolution module
which goes through an algorithm similar to the following.
Negative conditionals indicate an end of processing and a
discarding of the packet.

?Do I have the hardware type in ar$hrd?
Yes: (almost definitely)
  [optionally check the hardware length ar$hln]
  ?Do I speak the protocol in ar$pro?
  Yes:
    [optionally check the protocol length ar$pln]
    Merge_flag := false
    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 and set Merge_flag to true.
    ?Am I the target protocol address?
    Yes:
      If Merge_flag is false, add the triplet <protocol type,
          sender protocol address, sender hardware address> to
          the translation table.
      ?Is the opcode ares_op$REQUEST?  (NOW look at the opcode!!)
      Yes:
        Swap hardware and protocol fields, putting the local
            hardware and protocol addresses in the sender fields.
        Set the ar$op field to ares_op$REPLY
        Send the packet to the (new) target hardware address on
            the same hardware on which the request was received.

Notice that the <protocol type, sender protocol address, sender
hardware address> triplet is merged into the table before the
opcode is looked at.  This is on the assumption that communcation
is bidirectional; if A has some reason to talk to B, then B will
probably have some reason to talk to A.  Notice also that if an
entry already exists for the <protocol type, sender protocol
address> pair, then the new hardware address supersedes the old
one.  Related Issues gives some motivation for this.

Seguindo a Edição 1, a segunda solicitação ARP do host de destino antes de qualquer resposta de eco ICMP indica que o endereço MAC de origem não está em seu cache ARP ou se tornou OBSOLETO, acionando assim outra solicitação ARP antes de responder à solicitação de eco ICMP.

Há uma seção no final do RFC que discute isso. Não há nada no RFC que exija que uma entrada de tabela ARP atinja o tempo limite, mas é uma prática comum entre fornecedores de SO fazer isso. A discussão do RFC começa assim:

Related issue:
---------------

It may be desirable to have table aging and/or timeouts.  The
implementation of these is outside the scope of this protocol.