앞서 예제를 계속해 보면, 호스트 A가 아직 호스트 B의 MAC 주소를 모르는 경우 ARP 요청 패킷을 만드는데, 오퍼레이션 필드는 1로, 발신지 프로토콜 주소 필드는 18.19.0.1로, 발신지 하드웨어 필드는 01:01:01:00:00:10, 목적지 프로토콜 주소 필드는 18.19.0.2로 각각 설정한다. 다음 이 패킷을 이더넷 프레임에 감싸 이더넷 브로드캐스트 주소 FF:FF:FF:FF:FF:FF로 발신한다. 브로드캐스트 주소를 사용하면 네트워크상 모든 호스트가 이 프레임을 받아 살펴보게 된다.
호스트 C는 패킷을 받아도 응답을 하지 않는다. 왜냐하면, IP 주소가 패킷상 목적지 프로토콜의 주소와 다르기 때문이다. 하지만 호스트 B는 IP가 일치하므로 자신의 ARP 패킷을 하나 만들어 응답하는데, 이때 자기 주소를 발신지로, 그리고 호스트 A의 주소를 목적지로 한다. 호스트 A가 패킷을 받으면 새로 받은 주소로 ARP 테이블의 호스트 B에 대한 MAC 주소를 갱신하고, 이를 기다리던 IP 패킷을 이더넷 프레임에 포함하여 호스트 B의 MAC 주소로 보낸다.
Note ≣
호스트 A가 ARP 요청을 네트워크상 모든 호스트에 처음 브로드캐스트할 때, 호스트 A 자신의 MAC 주소와 IP 주소를 포함해서 보낸다. 이렇게 하면 네트워크에 연결된 다른 호스트들이 호스트 A의 정보로 미리 ARP 테이블를 갱신해 둘 수 있다. 아직은 호스트 A의 정보가 필요 없다고 해도, 미리 갱신해 두면 나중에 통신할 필요가 생겼을 때 ARP 요청부터 보내지 않아도 되므로 요긴하다.
한편으론 이 시스템으로 인해 흥미로운 보안상 약점 또한 노출되는 것을 간파할 수 있을 것이다. 악성 호스트가 모든 IP를 자기 것인 양 조작한 ARP 패킷을 뿌릴 수 있다. ARP 정보가 검증된 것인지 확인할 방도가 없다면, 스위치 장비가 의도치 않게 모든 패킷을 악성 호스트에 전달해 바치는 결과가 나타날 수 있다. 이렇게 되면 패킷을 훔쳐보는 데 그치지 않고, 응당 전달되어야 할 패킷이 전달되지 못하여 네트워크 전체의 트래픽이 혼란에 빠지게 된다.