现代操作系统上的 ARP 表中的条目将超时。这不是RFC 826, An Ethernet Address Resolution Protocol的官方部分，尽管 RFC 最后确实讨论了它：

相关问题：

可能需要表老化和/或超时。这些的实现超出了本协议的范围。这是更详细的描述（感谢 MOON@SCRC@MIT-MC）。

如果主机移动，则该主机发起的任何连接都将起作用，假设它自己的地址解析表在移动时被清除。但是，其他主机向它发起的连接没有特别的理由知道要丢弃它们的旧地址。但是，48 位以太网地址应该是唯一的并且一直是固定的，所以它们不应该改变。如果将主机名（以及某些其他协议中的地址）重新分配给不同的物理硬件，则主机可以“移动”。另外，我们从经验中知道，错误的路由信息​​总是存在通过硬件或软件错误意外传输的危险；不应该让它永远存在。可能发起连接失败应该通知地址解析模块以主机不可访问为基础删除信息，可能是因为它已关闭或旧的转换不再有效。或者也许从主机接收数据包应该重置用于将数据包传输到该主机的地址解析条目中的超时；如果在适当的时间长度内没有从主机接收到数据包，则地址解析条目被遗忘。这可能会导致额外的开销来扫描每个传入数据包的表。也许散列或索引可以使这更快。如果在适当的时间长度内没有从主机接收到数据包，则地址解析条目被遗忘。这可能会导致额外的开销来扫描每个传入数据包的表。也许散列或索引可以使这更快。如果在适当的时间长度内没有从主机接收到数据包，则地址解析条目被遗忘。这可能会导致额外的开销来扫描每个传入数据包的表。也许散列或索引可以使这更快。

接收地址解析数据包的建议算法试图减少主机移动时恢复所需的时间。回想一下，如果 <protocol type, sender protocol address> 已经在转换表中，那么发送者硬件地址将取代现有条目。因此，在一个广播请求到达电缆上所有站点的完美以太网上，每个站点都将获得新的硬件地址。

另一种选择是让守护程序执行超时。在适当的时间之后，守护进程考虑删除一个条目。它首先直接向表中的以太网地址发送一个带有操作码 REQUEST 的地址解析数据包（如果需要，可以进行少量重传）。如果在短时间内没有看到回复，则删除该条目。该请求被直接发送，以免打扰以太网上的每个站点。只是忘记条目可能会导致忘记有用的信息，必须重新获得这些信息。

由于主机不会传输除自己以外的任何人的信息，重新启动主机将导致其地址映射表是最新的。不良信息不能通过在机器之间传递而永远存在；唯一可能存在的坏信息是在不知道其他机器已更改其 48 位以太网地址的机器中。也许手动重置（或清除）地址映射表就足够了。

如果认为这个问题很重要，显然需要更多的思考。它是由任何类似地址解析的协议引起的。

根据您的评论进行编辑：

协议理论不涵盖您的情况，它取决于操作系统特定的实现。不幸的是，我们无法回答特定主机会做什么，因为这取决于主机操作系统，这在此处是题外话。不同的操作系统，甚至同一个操作系统的不同版本，可以做不同的事情。对于发生的事情没有一个答案。

我知道这不是一个非常令人满意的答案（甚至有人投了反对票），但这是现实。您可能会发现某个特定主机在做某事，但您不能依赖任何其他主机（尤其是使用不同操作系统的主机）做同样的事情。正如 Zac67 所指出的，一个主机操作系统在更改其地址时可能会发送一个免费的 ARP，但这并不能保证其他主机也会​​做同样的事情。

ARP 是添加到 IPv4 的东西，它实际上并不是 IPv4 的一部分，但它是一个单独的过程。创建 IPv6 时已考虑到该问题，并且 IPv6 已在其中内置 NDP（邻居发现协议），除其他外，它取代了 ARP，它解决了您在 ARP 中指出的问题。

除了 Ron 描述的超时，更改其 IP 地址的设备通常会发送一个免费的ARP（GARP - 通常是对自身的请求）作为广播，以通知网络 MAC 地址更改。

当您使用没有虚拟 MAC 地址的虚拟 IP 地址时，GARP 尤其重要。