Address Resolution Protocol

The Address Resolution Protocol (ARP) is a communication protocol used for discovering the link layer address, such as a MAC address, associated with a given internet layer address, typically an IPv4 address. This mapping is a critical function in the Internet protocol suite.

ARP has been implemented with many combinations of network and data link layer technologies, such as IPv4, Chaosnet, DECnet and Xerox PARC Universal Packet (PUP) using IEEE 802 standards, FDDI, X.25, Frame Relay and Asynchronous Transfer Mode (ATM).

In Internet Protocol Version 6 (IPv6) networks, the functionality of ARP is provided by the Neighbor Discovery Protocol (NDP).

Operating scope

The Address Resolution Protocol is a request-response protocol. Its messages are directly encapsulated by a link layer protocol. It is communicated within the boundaries of a single network, never routed across internetworking nodes.

Frame Structure

The Address Resolution Protocol uses a simple message format containing one address resolution request or response. The packets are carried at the data link layer of the underlying network as raw payload. In the case of Ethernet, a 0x0806 EtherType value is used to identify ARP frames.

Frame Header

The EtherType for ARP is 0x0806. This appears in the Ethernet frame header when the payload is an ARP packet and is not to be confused with PTYPE, which appears within this encapsulated ARP packet.

A typical header of ARP frame is 14 bytes

6-byte destination mac address | 6-byte source mac address | 2-byte EtherType

ARP Packet structure

The size of the ARP message depends on the link layer and network layer address sizes. The message header specifies the types of network in use at each layer as well as the size of addresses of each. The message header is completed with the operation code for request and reply . The payload of the packet consists of four addresses, the hardware and protocol address of the sender and receiver hosts.

The principal packet structure of ARP packets is shown in the following table which illustrates the case of IPv4 networks running on Ethernet. In this scenario, the packet has 48-bit fields for the sender hardware address (SHA) and target hardware address (THA), and 32-bit fields for the corresponding sender and target protocol addresses (SPA and TPA). The ARP packet size in this case is 28 bytes.

ARP protocol parameter values have been standardized and are maintained by the Internet Assigned Numbers Authority (IANA).[2]

Hardware type (HTYPE)

This field specifies the network link protocol type. Example: Ethernet is 1

Protocol type (PTYPE)

This field specifies the internetwork protocol for which the ARP request is intended. For IPv4, this has the value 0x0800. The permitted PTYPE values share a numbering space with those for EtherType

Hardware length (HLEN)

Length (in octets) of a hardware address. Ethernet address length is 6.

Protocol length (PLEN)

Length (in octets) of internetwork addresses. The internetwork protocol is specified in PTYPE. Example: IPv4 address length is 4.

Operation

Specifies the operation that the sender is performing: 1 for request, 2 for reply.

Sender hardware address (SHA)

Media address of the sender. In an ARP request this field is used to indicate the address of the host sending the request. In an ARP reply this field is used to indicate the address of the host that the request was looking for.

Sender protocol address (SPA)

Internetwork address of the sender.

Target hardware address (THA)

Media address of the intended receiver. In an ARP request this field is ignored. In an ARP reply this field is used to indicate the address of the host that originated the ARP request.

Target protocol address (TPA)

Internetwork address of the intended receiver.

Frame Examples

Run the following command to capture arp packet

sudo tcpdump -i [interface name] arp -ne -xx

The packet captured

06:55:28.198569 d4:d2:52:ad:c6:bd > 52:54:00:8d:63:62, ethertype ARP (0x0806), length 60: Request who-has 192.168.9.154 (52:54:00:8d:63:62) tell 192.168.9.142, length 46

	0x0000:  5254 008d 6362 d4d2 52ad c6bd 0806 0001

	0x0010:  0800 0604 0001 d4d2 52ad c6bd c0a8 098e

	0x0020:  5254 008d 6362 c0a8 099a 0000 0000 0000

	0x0030:  0000 0000 0000 0000 62f2 9c01

Length 60 is because, the minimum legal length of ethernet packet is 64 octets, including the FCS. ARP requests from local are 42 octets long, ARP requests from remote are 60 octets long. Normal Ethernet padding for packets smaller than 64 bytes (header + user data + FCS). If FCS is not displayed, the packets you observe are 60 bytes long.

06:55:28.198620 52:54:00:8d:63:62 > d4:d2:52:ad:c6:bd, ethertype ARP (0x0806), length 42: Reply 192.168.9.154 is-at 52:54:00:8d:63:62, length 28

	0x0000:  d4d2 52ad c6bd 5254 008d 6362 0806 0001

	0x0010:  0800 0604 0002 5254 008d 6362 c0a8 099a

	0x0020:  d4d2 52ad c6bd c0a8 098e

Length 28 is hex, equal to decimal 42
Frame header: destination mac addr [d4d2 52ad c6bd] source mac addr [5254 008d 6362] ethertype ARP [0806] request/reply [0001]
ARP packet: protocol type [0800] hardware addr length [06] protocol addr length [04] operation, 1:request,2:reply [0002]

sender hardware addr [5254 008d 6362] sender protocol addr [c0a8 099a]

target hardware addr [d4d2 52ad c6bd] target protocol addr [c0a8 098e]

Minimum Packet Size

1

If you look more carefully, you will notice that all frames which are shorter than the minimum frame size (60 bytes without FCS) are frames which are transmitted by your machine. Received frames should be padded to 60 bytes without FCS; they contain the “Padding” field under “Ethernet II” in the Wireshark “Packet Details” window, which corresponds to those extra bytes.

At least in Linux, all transmitted frames which are shorter than 60 bytes should be automatically padded by the network driver (or even NIC hardware) before the transmission, but Wireshark does not show this, because frames are copied to the packet socket used by Wireshark before that padding is added.

Originally the minimum frame size was specified to make the CSMA/CD protocol used for the shared Ethernet medium work properly — reliable collision detection requires that the time needed to transmit a frame (which is proportional to its size together with all headers and preamble) must be greater than the signal propagation time between any two stations. Current Ethernet is in most cases not actually a shared medium (switches with full-duplex links do not perform collision detection). Technically enforcing a minimum frame size would not be required on a full-duplex link, but it is still done for compatibility reasons.

Since Gigabit Ethernet the 64-byte minimum frame size is no longer enough for collision detection when using practical cable lengths, and simply increasing the minimum frame size would lead to significant waste of bandwidth, therefore the Carrier Extension mechanism is introduced for half-duplex gigabit links (see also here for more information). Carrier extension is implemented in network hardware and not visible to software. In theory, using carrier extension makes enforcing the minimum frame size optional for half-duplex links, and with full-duplex links neither carrier extension nor minimum frame size are needed. However, the 64-byte minimum frame size is still kept, probably for compatibility with old software which could expect it.

2

The entire frame has to be at least 64 bytes. This is not just the payload, this includes the headers and the frame check sequence. The FCS takes up 4 bytes at the end. An Ethernet header consists of two 6 byte MAC addresses plus a 2 byte type field, 14 bytes in total. 64-4-14 = 46. IPv4 packets have an additional header of at least 20 bytes on top of the Ethernet header, making the minimum payload size 26 bytes. TCP and UDP add more headers on top of that.

Another thing to note is that the size of a minimum length frame on the wire is actually larger than 64 bytes - there is an 8 byte preamble/start of frame delimiter and a 12 byte interframe gap that get attached to every packet, making a 64 byte packet take up 64+8+12 = 84 bytes on the wire.

The 41 byte answer on the other question is only considering TCP and IP headers. If you send a TCP packet with 0 data bytes, it will have 40 bytes of headers; it's not possible to make a valid TCP packet smaller than this. But if you try to send this packet, it will get zero padded out to 46 bytes before the Ethernet FCS is attached.

The reason this was originally done with Ethernet was to ensure a minimum frame length on the wire so that collisions could be reliably detected by all devices over the specified maximum cable length. This is required because early incarnations of 10M Ethernet used a shared coaxial medium and connected devices had to be able to detect when two of them tried to transmit on the shared medium at the same time. Slightly less ancient 10M and 100M Ethernet networks over twisted pair that were built with hubs instead of switches also needed to be able to detect collisions. However, most modern Ethernet networks are switched and do not use a shared medium, so this is no longer strictly necessary, but it's still part of the spec for compatibility reasons. Frames shorter than 64 bytes are called runt frames, and if you see runt frames in a network that usually indicates some sort of configuration or hardware issue.

C Code Of Generating AN ARP Packet

ARP(Address Resolution Protocol) Packet