While an IPv4 ARP resolution is pending, what must a host or router do with waiting packets, and when may it report failure?

## The window nobody notices until it bites When a host or router has a packet for a next hop with no ARP cache entry, it broadcasts an ARP request and waits for the reply. On a healthy LAN that window is short, but it is real, and it is the first thing that happens at the start of almost every conversation after an entry has expired. The specifications say what to do with traffic that arrives during it, and what to tell the sender if the answer never comes. ## What host requirements say RFC 1122 sets three rules for this window: | Section | Rule | Strength | |---|---|---| | §2.3.2.2 | save at least one (the latest) packet of each set destined to the same unresolved IPv4 address, and transmit it once resolved | SHOULD | | §2.3.2.1 | prevent ARP flooding; recommended maximum 1 request per second per destination | MUST include a mechanism | | §2.4 | do not report Destination Unreachable to IP solely because there is no ARP cache entry | MUST NOT | The queue can be tiny. "At least one (the latest)" means a host that keeps only the newest packet and drops earlier ones still complies; what it must not do is throw every unresolved packet away. ## Why the first packet matters RFC 1122's discussion spells out the cost of discarding: - the first packet of **every** exchange is lost whenever the entry had to be resolved; - for TCP, losing the opening segment means a retransmission timeout, and it inflates the initial round-trip time estimate; - for UDP protocols such as DNS the damage is worse, because the application itself has to notice the silence and retry. This is the protocol-level explanation for a familiar symptom: the very first request to a rarely contacted local host is noticeably slower than the rest, or a single UDP query times out and the retry succeeds. An implementation that queues correctly hides almost all of this; one that discards turns every expired entry into a lost packet, and the busier the link's turnover of entries, the more often users feel it. ## What router requirements add RFC 1812 §3.3.2 restates the same duty for routers forwarding to a directly connected network: 1. Do not report the destination unreachable just because there is no entry yet. 2. Queue up to a small number of datagrams briefly while the request and reply run. 3. Report the destination unreachable for one of the queued datagrams only when resolution proves fruitless. The ICMP message for that case is **Destination Unreachable (type 3), code 1, Host Unreachable**. RFC 1812 §5.2.7.1 describes code 1 as generated by a router when the forwarding path to a host on a directly connected network is not available, "does not respond to ARP". Compare code 0, Network Unreachable, for a destination with no route at all, and code 3, Port Unreachable, which comes from the destination host itself. ## A stale entry is a different failure Pending resolution fails **loudly**: the router knows it never got an answer and can say so. An entry that resolved to a MAC that no longer exists fails **silently**: the frame is handed to Ethernet, which has no delivery acknowledgement, and nobody reports anything. Telling the two apart is a large part of many "one host is unreachable" investigations: - Host Unreachable arriving from the last router means ARP got no answer on the destination's link; - timeouts with no ICMP at all, for a host that clearly holds an entry, point to a wrong cached MAC. ## The IPv6 contrast IPv6 has no ARP, but Neighbor Discovery makes the same rules stronger. RFC 4861 says a node MUST queue at least one packet per neighbour awaiting resolution and SHOULD replace the oldest on overflow, and when resolution fails it MUST return ICMPv6 Destination Unreachable with **code 3, Address Unreachable**, for each queued packet. Same idea, different message and different code; do not carry the IPv6 code over to IPv4. ## Misconceptions - "A missing ARP entry makes the host answer Destination Unreachable at once" is exactly what RFC 1122 forbids. - "Packets are dropped while ARP runs" describes a non-compliant implementation, not the rule. - "The switch sends Host Unreachable" misplaces the message; an IPv4 router, which knows it tried ARP, generates it.