有些arp请求报文中为什么会有目的mac地址(不使用广播地址)
2017-10-01 16:53
211 查看
转载自:AprilCal:http://www.cnblogs.com/AprilCal/
实际中遇到!有些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 toMOON@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地址,或者已经离开了此以太网,直接删除此表项即可。
相关文章推荐
- 有些arp请求报文中为什么会有目的mac地址(不使用广播地址)
- 有些arp请求报文中为什么会有目的mac地址(不使用广播地址)
- SNMP使用UDP传送报文。为什么不使用TCP?
- 通过arp请求获取苹果手机的mac地址
- 使用tcpdump观察ARP通信过程和ARP报文详解
- How to :使用ARP命令来绑定IP和MAC地址
- 使用WindowsAPI发送ARP请求获得MAC地址
- 使用X-Forwarded-For字段修改报文请求ip
- 网络请求为什么要使用第三方库???
- 010 使用netmap API接管网卡,接收数据包,回应ARP请求
- 使用WindowsAPI发送ARP请求获得MAC地址
- 11.4.8 使用SOCK_PACKET编写ARP请求程序的例子
- post 相比get 有很多优点,为什么现在的HTTP通信中大多数请求还是使用get
- post 相比get 有很多优点,为什么现在的HTTP通信中大多数请求还是使用get?
- 为什么不建议使用*{padding:0;margin:0;}进行reset?reset的目的是什么??
- spring boot 使用Aop通知打印控制器请求报文和返回报文问题
- 使用netfilter框架处理ARP报文
- 为什么有些Office对象的事件无法使用
- PostMan使用模拟http请求 发送xml报文请求
- 使用python实现判断HTTP请求报文是否结束的判断。