The following questions may not be immediately clear:
- The "new" messages do not extend the protocol - they do not introduce new ARP message types. How can one speak about "new messages"?
- Source and destination MAC addresses are naturally present in the MAC headers of the ARP message. But there are also "Source Hardware Address" (SHA) and "Target Hardware Address" (THA) fields in the ARP message body, which are also MAC addresses. How are the former and the latter related, and why seemingly the same information is duplicated?
|Message||Sent when the host...||MAC headers||ARP body|
|src MAC||dst MAC||message type||SHA (MAC)||SPA (IP)||THA (MAC)||TPA (IP)|
|request||wants to send an IP packet, but does not know the MAC address of the destination||own||broadcast||REQUEST||own||own||0||destination's|
|reply||receives an ARP request to an IP address this host owns||own||destination's, or broadcast1||REPLY||own||own||requestor's||requestor's|
|probe (RFC 5227, 2.1)||configures a new IP address for an interface||own||broadcast||REQUEST2||own||03||0||probed|
|announcement (RFC 5227, 2.3)||after a probe, concludes that it will use the probed address||own||broadcast||REQUEST2||own||new own||0||new own|
Notes to the table:
- RFC 5227, section 5.6 explains why "Broadcast replies are not universally recommended, but may be appropriate in some cases".
- RFC 5227, section 3 notes that the type here could be REPLY as well, then continues to give reasons why REQUEST is recommended.
- Zero is specified here in order not to pollute ARP caches of other hosts in case when the probed address is already used in this LAN and the probing host will not take it.