ARP Network monitoring and debugging:

Question

I am reading the RFC 826, however I am unable to get the context behind the Network monitoring and debugging section:

Network monitoring and debugging:

The above Address Resolution protocol allows a machine to gain knowledge about the higher level protocol activity (e.g., CHAOS, Internet, PUP, DECnet) on an Ethernet cable. It can determine which Ethernet protocol type fields are in use (by value) and the protocol addresses within each protocol type. In fact, it is not necessary for the monitor to speak any of the higher level protocols involved. It goes something like this:

When a monitor receives an Address Resolution packet, it always enters the in a table. It can determine the length of the hardware and protocol address from the ar$hln and ar$pln fields of the packet. If the opcode is a REPLY the monitor can then throw the packet away. If the opcode is a REQUEST and the target protocol address matches the protocol address of the monitor, the monitor sends a REPLY as it normally would. The monitor will only get one mapping this way, since the REPLY to the REQUEST will be sent directly to the requesting host. The monitor could try sending its own REQUEST, but this could get two monitors into a REQUEST sending loop, and care must be taken.

Because the protocol and opcode are not combined into one field, the monitor does not need to know which request opcode is associated with which reply opcode for the same higher level protocol. The length fields should also give enough information to enable it to "parse" a protocol addresses, although it has no knowledge of what the protocol addresses mean.

A working implementation of the Address Resolution protocol can also be used to debug a non-working implementation. Presumably a hardware driver will successfully broadcast a packet with Ethernet type field of ether_type$ADDRESS_RESOLUTION. The format of the packet may not be totally correct, because initial implementations may have bugs, and table management may be slightly tricky. Because requests are broadcast a monitor will receive the packet and can display it for debugging if desired.

I apologize for this vague question, however I am not able to understand what the difference between the ARP module and this process for monitor and debugging.

Answer 1

Assume you have a LAN with multiple hosts, and you want to test an ARP implementation you are developing. You can set up one host to monitor network traffic which it receives using something like Wireshark. This host is only for monitoring and debugging your ARP implementation. If ARP used unicast, you would need to have your monitoring host participate since it would only receive frames sent directly to it, but because ARP uses broadcast, every host on the LAN, including the non-participating monitoring host, will receive ARP frames. The monitoring host can capture and decode ARP frames without participating in the testing. This allows you to see if the ARP implementation is properly encoding per the RFC.