有些arp請求報文中為什么會有目的mac地址(不使用廣播地址)
最近做實驗，注意到局域網內大部分的arp包的以太網頭部目的mac地址並不是廣播地址，並且包內的目的mac地址字段並不是全0，而是目的ip對應的mac地址(顯然，此目的mac地址來源於計算機內緩存的arp表)。
如圖：
可以看出來，此arp請求包的以太網頭部並沒有使用廣播地址，並且包內的目的mac地址字段並不是全0，而是和以太網頭部的mac地址相同。
大部分講述arp報文格式的文獻中都會詳細的介紹此字段並且告訴你，在沒有目的ip地址對應的mac地址時，以太網地址解析模塊會發送一個請求arp報文，並且包內的目的mac地址字段是全零(顯然，因為並不知道此mac地址)。以圖中的arp請求報文為例，首先以太網頭部中的目的地址字段不是廣播地址，其次包內目的地址字段不是全0.
查閱相關文檔[RFC 826],其中
Related issue:
It may be desirable to have table aging and/or timeouts. The implementation of these is outside the scope of this protocol. Here is a more detailed description (thanks to MOON@SCRC@MIT-MC).
If a host moves, any connections initiated by that host will work, assuming its own address resolution table is cleared when it moves. However, connections initiated to it by other hosts will have no particular reason to know to discard their old address. However, 48.bit Ethernet addresses are supposed to be unique and fixed for all time, so they shouldn't change. A host could "move" if a host name (and address in some other protocol) were reassigned to a different physical piece of hardware. Also, as we know from experience, there is always the danger of incorrect routing information accidentally getting transmitted through hardware or software error; it should not be allowed to persist forever. Perhaps failure to initiate a connection should inform the Address Resolution module to delete the information on the basis that the host is not reachable, possibly because it is down or the old translation is no longer valid. Or perhaps receiving of a packet from a host should reset a timeout in the address resolution entry used for transmitting packets to that host; if no packets are received from a host for a suitable length of time, the address resolution entry is forgotten. This may cause extra overhead to scan the table for each incoming packet. Perhaps a hash or index can make this faster. The suggested algorithm for receiving address resolution packets tries to lessen the time it takes for recovery if a host does move. Recall that if the (protocol type, sender protocol address) is already in the translation table, then the sender hardware address supersedes the existing entry. Therefore, on a perfect Ethernet where a broadcast REQUEST reaches all stations on the cable, each station will be get the new hardware address.
Another alternative is to have a daemon perform the timeouts. After a suitable time, the daemon considers removing an entry. It first sends (with a small number of retransmissions if needed) an address resolution packet with opcode REQUEST directly to the Ethernet address in the table. If a REPLY is not seen in a short amount of time, the entry is deleted. The request is sent directly so as not to bother every station on the Ethernet. Just forgetting entries will likely cause useful information to be forgotten, which must be regained.
Since hosts don't transmit information about anyone other than themselves, rebooting a host will cause its address mapping table to be up to date. Bad information can't persist forever by being passed around from machine to machine; the only bad information that can exist is in a machine that doesn't know that some other machine has changed its 48.bit Ethernet address. Perhaps manually resetting (or clearing) the address mapping table will suffice.
This issue clearly needs more thought if it is believed to be important. It is caused by any address resolution-like protocol.
加粗段落指出，每隔一段合適的時間，后台進程會考慮移除一條表項(每條表項都有對應的生存時間)，在移除此表項前，會先直接發送一條地址解析包到表中對應的以太網地址，如果在短時間內沒有回復，則刪除此表項。請求包是直接發送到目的地的，所以可以不打擾到以太網中的其他站點；而直接刪除此表項會造成有用的信息被刪除，並且需要重新來獲取此信息。
這樣答案就很明顯了。如果arp表中的表項生存時間一到，直接刪除此表項，則還需要重新發送廣播幀來請求目的mac地址，這樣做因為廣播而打擾其他站點。考慮到如果以太網中的主機很多，那么每台機器中的arp表中的表項也會很多，如果每條表項生存時間一到就直接刪除表項，那么局域網中的廣播數量會很多，這會在一定程度上影響網絡的利用率，因此在刪除表項之前，直接向該表項的目的地址發送一條請求報文來確認。如果短時間內沒有收到回復，則說明此mac地址的擁有者已經改變了ip地址，或者已經離開了此以太網，直接刪除此表項即可。
AprilCal on May 2017.
mail:15527358829@qq.com