ARP notes

For other network related things, see: Networking basics - General Layer 2 mostly - On MACs and EUIs · ARP notes · ping notes · Spanning tree notes · Bridging notes · DHCP notes · Layer 2 unsorted notes Layer 3 (IP mostly) - sockety things · IPv4 notes · IPv6 notes Firewalling and other packet stuff wireshark and tshark notes · tcpdump notes · nmap notes · other network tools Also: Network wiring notes - 8P8C / RJ45 Network wiring notes - Power over Ethernet Wireless communication IO and wired communication More technical VPN notes

✎ This article/section is a stub — some half-sorted notes, not necessarily checked, not necessarily correct. Feel free to ignore, or tell me about it.

For context, consider that wired home LANs are usually Ethernet, and within a Ethernet network, packets are sent to MAC addresses.

That's all that its layer 2 does, or can do.

We usually mostly carry IP on top (Layer 3), but by the nature of the layers, that is not something that the hardware of Ethernet (layer 2) cares about.

Yet IP became so ubiquitous that some amount of added integration between IP and Ethernet would be great.

ARP is mainly used to find a MAC when the IP is known, so that you can think in IP addresses instead, and there is something doing the translation for you.

ARP's packets carry little more than something like

"Who has 192.168.178.29? Tell 192.168.178.1"

And responses (from the node with that address, usually unicast to the node that sent the request)

"192.168.178.29 is at 74:d4:35:01:23:45"

(which is basically what tcpdump arp -n will say)

Whenever a node sees such a response, it keeps the (mac,ip) pairs in a table.

When a PC is asked to send to an IP that does not have such an entry, it cannot construct the layer 2 packet (it needs the MAC desination), which means the OS will first send such a request.

Notes:

• What failure to do so means within a program depends on exactly what network call you were making)
• A program could decide to broadcast at layer 2 instead, but it's a specific choice.
• In theory the OS also could, but it won't for many reasons
• ARP is specific to IP's version 4 - IPv6 instead uses Neighbor Discovery Protocol (and its Secure Neighbor Discovery extension).

And because that leads to ARP requests and responses, this is also really useful for the layer-2 switching involved (Ethernet switches), in that ARP responses will have the side effect of telling the switch which physical port a particular MAC is attached to.

Because before it knows what wire a node with a particular MAC is on, it can only deliver it by sending it on all.

Yet in practive that is rare, because when you ask an OS to send to an IP, its first response is ARP.

While that node behaviour is unrelated to the switch, switch's learning is purely passive, in practice the switch will almost always see ARP responses learning the port, before seeing other data towards that port.

Notes:

• yes, there are exceptional situations, that aren't great
• switches still don't need to know about the IP layer, and what they learn from ARP is still only used for layer 2.

technically, ethernet switches parsing packets that support a specific layer 3 protocol, but only for layer 2 benefits, and it would function without

(ARP is such a simple structure that they can parse it specifically)

yes, ethernet switches can parse some other layer 3 packets, but primarily for specific features of managed switches, or things like multicast

ARP has other uses, such as the allowing a DHCP client to double check whether the IP it just got is already in use (in its broadcast domain), before creating what might be an IP conflict. This is optional, but a good idea.