De acuerdo con el RFC826 (Protocolo de resolución de direcciones Ethernet), el remitente debe:
Ponga el hardware local y las direcciones de protocolo en los campos del remitente
Pero, como señaló, ¿por qué un anfitrión usaría la dirección de transmisión en una respuesta ARP? Tal vez porque esto podría parecer inteligente: al usar la dirección de transmisión L2, todos los hosts en la LAN sabrían inmediatamente un nuevo par (IP, MAC) para ahorrar tiempo. En realidad, el RFC no desea este método (incluso si se refieren a la transmisión periódica):
La transmisión periódica definitivamente no es deseable. Imagine 100 estaciones de trabajo en una sola Ethernet, cada una transmitiendo información de resolución de dirección una vez cada 10 minutos (como un posible conjunto de parámetros). Este es un paquete cada 6 segundos. Esto es casi razonable, pero ¿de qué sirve? Las estaciones de trabajo generalmente no van a hablar entre sí (y por lo tanto tienen 100 entradas inútiles en una tabla);
También depende del sistema operativo del host para agregar en la tabla ARP una tupla aprendida por un mensaje emitido.
EDITAR: Como se indica en los comentarios, el RFC 5227 actualiza el RFC 826 y dice
En algunas aplicaciones de Detección de conflictos de direcciones IPv4 (ACD), puede ser ventajoso entregar respuestas ARP utilizando difusión en lugar de unidifusión, ya que esto permite detectar conflictos de direcciones antes de lo que podría suceder
Uno de los usos de la transmisión ARP son las respuestas ARP gratuitas enviadas por algunas soluciones de agrupamiento o agregación de enlaces (es decir, agrupación). Este es el proceso que normalmente usarán cuando quieran mover el tráfico de una interfaz a otra.
Este proceso actualizará todos los hosts en la subred local (incluida la puerta de enlace) y hará que los conmutadores L2 actualicen sus tablas de direcciones MAC. El resultado es que todo el tráfico debería pasar a la nueva interfaz sin problemas y rápidamente.
fuente