Link-Layer Forensics: From Ethernet II Frames to ARP Spoofing

 

The link layer (also called the network access layer in the TCP/IP model) governs how data frames are transmitted between nodes over a local link. Common LAN technologies include IEEE 802.3 Ethernet and IEEE 802.11 Wi-Fi, although the link layer is not limited to the IEEE 802 family. Other data-link technologies include PPP, HDLC, Frame Relay, and ATM. Our primary concern is how a host resolves a known network-layer (IP) address into the link-layer address required to construct a frame. In IPv4, the Address Resolution Protocol (ARP) resolves an IPv4 address to a link-layer address; the older Reverse Address Resolution Protocol (RARP), which performed a different function, is now obsolete. The resolved MAC address belongs to the next hop on the local link, not necessarily the final destination. For off-subnet traffic, this is typically the default gateway, making the gateway's ARP cache entry a potential target for ARP spoofing.

In IPv6, ARP is replaced by the Neighbor Discovery Protocol (NDP), which operates over ICMPv6. Neighbor Solicitation messages use ICMPv6 type 135, while Neighbor Advertisement messages use type 136. For address resolution on multicast-capable links, a Neighbor Solicitation is sent to the target's solicited-node multicast address (ff02::1:ffXX:XXXX), derived from the low-order 24 bits of the target IPv6 address, rather than being broadcast to every host on the local link. Neighbor Solicitations can also be sent as unicast messages for reachability checks.

Both protocols are associated with volatile operating-system artifacts: the IPv4 ARP cache and the IPv6 neighbor cache. These caches record IP-to-link-layer address associations and can help investigators reconstruct local network activity, provided the entries are captured before they expire or are replaced. Ordinary ARP lacks authentication, making it vulnerable to ARP spoofing. NDP also faces threats such as rogue Neighbor Advertisements, although IPv6 defines validation measures and Secure Neighbor Discovery (SEND) as an additional protection mechanism. Other Layer 2 attacks, including MAC flooding and VLAN hopping, exploit different aspects of network switching and segmentation.

Because MAC addresses can be spoofed or changed, a MAC address observed in a cache, packet capture, or switch forwarding table represents an observed or claimed link-layer identity, not definitive proof of a particular physical device or actor. Investigators should corroborate such evidence with independent sources, such as DHCP records, switch-port information, endpoint logs, and other relevant network telemetry. First, however, we will examine how Ethernet framing works.

IEEE 802.x Link Layer

The IEEE (Institute of Electrical and Electronics Engineers, commonly pronounced “I-triple-E”) develops and maintains the 802 family of LAN and MAN standards, including wireless networking standards such as 802.11. For our purposes, the most relevant member is IEEE 802.3, which specifies Ethernet. The terms “IEEE 802.3 framing” and “Ethernet II framing” are often conflated, but they describe different interpretations of the field following the source MAC address.

In Ethernet II, this 2-byte field is an EtherType identifying the encapsulated protocol, such as 0x0800 for IPv4, 0x0806 for ARP, and 0x86DD for IPv6. The resulting Ethernet II header is 14 bytes long: 6 bytes for the destination MAC address, 6 bytes for the source MAC address, and 2 bytes for the EtherType. In IEEE 802.3 length-based framing, the corresponding field specifies the length of the MAC client data, and the upper-layer protocol is identified through an IEEE 802.2 LLC header, optionally followed by a SNAP header. When LLC/SNAP encapsulation uses 8 bytes within a conventional 1500-byte Ethernet payload, up to 1492 bytes remain for the encapsulated IP packet.

Packet analyzers distinguish the two formats using the field's value: values up to and including 1500 (0x05DC) indicate a length, while values of 1536 (0x0600) and above indicate an EtherType. Values between these ranges are reserved. IEEE 802.3 revisions have accommodated EtherType-based framing, and Ethernet II is the dominant format for ordinary IP traffic on enterprise networks. LLC-based framing remains relevant in certain control protocols, including spanning-tree BPDUs. We will therefore focus on Ethernet II.

Even as workloads migrate to the cloud, Ethernet remains important in virtualized environments, where virtual switches and network interfaces provide Ethernet-like connectivity. Network-layer and higher-layer analysis remains applicable across physical and virtual environments, although Layer 2 visibility in cloud deployments depends on the provider's architecture and the telemetry it exposes, such as packet mirroring and flow logs.

Ethernet was significant in part because of its approach to sharing a communication medium. Earlier contention-based methods included ALOHA and carrier-sense multiple access (CSMA), while other networks used approaches such as time-slotted access or token passing. Robert Metcalfe’s design at Xerox PARC added collision detection (CD): Stations listened for carrier activity before transmitting, detected collisions while transmitting, sent a jam signal, and then retried after a randomized backoff using binary exponential backoff. This is CSMA/CD, which historically defined shared-medium Ethernet. On modern switched, full-duplex Ethernet links, CSMA/CD is no longer used, since each port is its own collision domain: each full-duplex link provides separate transmit and receive paths, eliminating the collisions that CSMA/CD was designed to manage.

Enterprise network monitoring commonly includes extensive wired-side visibility, while wireless monitoring addresses additional concerns such as detecting unauthorized access points and observing 802.11 management and radio activity. An ordinary wired capture on an access point's uplink generally sees traffic after it has been bridged or otherwise converted into Ethernet frames; it does not preserve the original 802.11 management frames or radio metadata.

On the wired side, the goal is to obtain the broadest practical packet visibility across relevant switches, routers, access points, and other network devices. However, a capture point sees only traffic that traverses the monitored link or is explicitly mirrored to it. Investigators must therefore plan TAP and SPAN deployments carefully, understand the limitations of each capture method, and account for possible packet loss on mirror ports. Traffic outside the monitored path remains invisible unless another collection point or telemetry source provides visibility.

An Ethernet II frame consists of a 14-byte header, a variable-length payload, and a 4-byte Frame Check Sequence (FCS). On the wire, it is preceded by an 8-byte lead-in consisting of a 7-byte preamble, used for synchronization, and a 1-byte Start Frame Delimiter (SFD), which marks the beginning of the frame. These bytes are handled by the physical-layer hardware and are normally absent from packet captures. The FCS is a CRC-32 value calculated over the MAC header and payload, including any padding, but excluding the preamble and SFD. It is normally checked by receiving hardware and is typically omitted from captures, although some network adapters and capture configurations can expose it.

Two forensic consequences follow. First, ordinary packet captures generally cannot establish whether corrupted frames were transmitted and discarded because of invalid FCS values. Specialized capture equipment may provide additional visibility into such frames. Some NICs can be configured to pass them (e.g., ethtool -K <if> rx-fcs on rx-all on on Linux). Second, incorrect transport-layer checksums in packets captured on the sending host may result from checksum offloading, whereby the NIC completes checksum calculations after the operating system's capture point. Such observations should not automatically be interpreted as evidence of corruption or malicious manipulation.

The Ethernet II header consists of a 6-byte destination MAC address, a 6-byte source MAC address, and a 2-byte EtherType field. The destination address appears first so that receiving hardware can determine whether a frame is addressed to the interface or a group it accepts. Ethernet supports unicast addressing, broadcast addressing using FF:FF:FF:FF:FF:FF, and multicast addressing. A multicast address is identified by the least significant bit of its first octet being set.

A NIC operating in promiscuous mode can accept frames regardless of their destination MAC address, subject to hardware, driver, and capture configuration. However, promiscuous mode does not bypass a switch's forwarding decisions. On a switched network, the interface ordinarily receives only traffic delivered to its port, including relevant broadcast and multicast traffic. Observing other unicast traffic generally requires an appropriate monitoring arrangement, such as a switch mirror port or network TAP.

The EtherType identifies the protocol encapsulated in the Ethernet payload. Common values include 0x0800 for IPv4, 0x0806 for ARP, and 0x86DD for IPv6. The value 0x8100 identifies the commonly used IEEE 802.1Q VLAN tag protocol. In a single-tagged frame, this value occupies the position normally used by the EtherType; it is followed by a 2-byte Tag Control Information (TCI) field and then the EtherType of the encapsulated protocol. The TCI contains priority information, a Drop Eligible Indicator (DEI), and the VLAN Identifier (VID). The tag adds 4 bytes to the MAC header, increasing its length from 14 to 18 bytes.

For an ordinary untagged Ethernet frame, the payload can range from 46 to 1500 bytes, with shorter data padded to satisfy the minimum frame size. For a single-tagged frame, the minimum payload can be 42 bytes while preserving the same 64-byte minimum frame size, measured from the destination MAC address through the FCS. Padding contents are not universally required to be zero, although zero-filled padding is common in modern implementations. Investigators may inspect padding when examining unusual or malformed frames but should not assume that it contains recoverable data from prior memory contents.

An untagged Ethernet frame has a standard maximum size of 1518 bytes, comprising a 14-byte header, a payload of up to 1500 bytes, and a 4-byte FCS. A frame with one 802.1Q tag can reach 1522 bytes. The 1500-byte figure is the conventional Ethernet payload limit, commonly used as the IP MTU. Some networks support larger payloads through jumbo-frame configurations, provided the relevant interfaces and network devices are configured accordingly.

Not every Ethernet frame uses Ethernet II encapsulation. In IEEE 802.3 length-based framing, the 2-byte field following the source MAC address indicates the length of the MAC client data rather than the encapsulated protocol. The protocol is then identified through an IEEE 802.2 Logical Link Control (LLC) header, which may be followed by a Subnetwork Access Protocol (SNAP) header. A basic LLC header is 3 bytes, while LLC combined with SNAP occupies 8 bytes. The MAC header remains 14 bytes when no VLAN tag is present, but the LLC/SNAP fields precede the network-layer data.

Packet analyzers distinguish length-based framing from Ethernet II using the field's value: values of 1500 (0x05DC) or less indicate a length, while values of 1536 (0x0600) or greater indicate an EtherType. The intervening range is reserved. Legacy Novell raw 802.3 framing, which omits LLC, can be identified by the FF FF signature immediately following the length field.

Although Ethernet II dominates ordinary IP traffic, LLC-based encapsulation remains important in infrastructure captures. Spanning Tree Protocol BPDUs typically use LLC directly, whereas Cisco Discovery Protocol (CDP), VLAN Trunking Protocol (VTP), and Dynamic Trunking Protocol (DTP) commonly use LLC/SNAP. Understanding these differences helps investigators identify control-plane traffic, select the correct packet-parser interpretation, and avoid misidentifying protocol headers during network analysis.

Ethernet frame length is constrained by the MAC frame format and the payload that follows the header. For conventional untagged Ethernet, the minimum frame size is 64 bytes, measured from the destination MAC address through the 4-byte Frame Check Sequence (FCS). With a 14-byte header and a 4-byte FCS, this leaves a minimum payload of 46 bytes. If the upper-layer data is shorter, the transmitting MAC pads the frame to meet the minimum size. This padding is not part of the upper-layer packet; the receiver uses the encapsulated protocol's length information, where available, to determine where the actual packet ends. Padding contents should not be assumed to be zero, although zero-filled padding is common in modern implementations.

The maximum conventional untagged frame is 1518 bytes: a 1500-byte payload plus the 14-byte header and 4-byte FCS. A single 802.1Q VLAN tag increases this to 1522 bytes. The 1500-byte payload limit is the conventional Ethernet maximum transmission unit (MTU), not an absolute physical limitation; some networks support larger payloads through jumbo-frame configurations.

The 64-byte minimum originated in Ethernet's use of Carrier Sense Multiple Access with Collision Detection (CSMA/CD). In shared-medium, half-duplex Ethernet, a transmitting station needed to remain in the process of transmitting long enough for a collision from the farthest part of the collision domain to be detected. The slot time was 512 bit times at 10 and 100 Mb/s. This requirement constrained the permissible collision-domain diameter, accounting for propagation and repeater delays. If a collision was detected after the slot time, it was classified as a late collision.

A late collision is not treated as an ordinary collision by the transmitting MAC, which generally reports a transmission error rather than performing the normal collision-retry procedure. Recovery therefore depends on higher-layer behavior where applicable. For example, TCP may retransmit lost data, whereas UDP does not provide retransmission itself and IP does not independently retransmit packets. Late-collision counters on a switch port can indicate a duplex mismatch, an improperly configured or oversized collision domain, or a physical-layer problem; the counters should be investigated alongside other interface and link diagnostics rather than treated as conclusive evidence of one cause.

On modern networks, CSMA/CD is largely a historical concern. Switched, full-duplex Ethernet links provide separate transmit and receive paths and do not experience the collisions addressed by CSMA/CD. Ten-Gigabit Ethernet and faster Ethernet standards operate in full-duplex mode. Although half-duplex Gigabit Ethernet was defined historically, it is essentially absent from modern deployments. The minimum frame size remains part of the Ethernet MAC format for compatibility and consistency, even though collision detection is no longer relevant to ordinary full-duplex links.

Packet-capture tools can alter the frame lengths visible to an investigator. Most capture interfaces omit the FCS, so a conventional untagged frame appears 4 bytes shorter: the minimum becomes 60 bytes and the maximum becomes 1514 bytes. Captures taken on the sending host may occur before the NIC adds Ethernet padding or performs other hardware processing, allowing shorter-than-minimum frames to appear in the capture. Conversely, segmentation and receive offloads can cause a capture to display oversized packets or aggregated data units that were never transmitted as individual Ethernet frames on the wire. These artifacts must be considered when interpreting packet lengths, investigating apparent MTU violations, or comparing endpoint captures with captures collected from a network TAP or switch mirror port.

Let us examine the Ethernet header in Wireshark. It consists of a destination MAC address, a source MAC address, and a 2-byte EtherType identifying the encapsulated protocol. Wireshark's packet summary commonly displays the source before the destination, but the expanded Ethernet header shows the fields in wire order: destination, source, and EtherType.

The destination address appears first so that receiving hardware can determine early whether a frame is addressed to the interface or to a group it accepts. Switches can also begin making forwarding decisions before the entire frame has arrived. The NIC performs destination-address filtering in hardware. Under normal operation, it accepts frames addressed to its own unicast MAC address, the broadcast address FF:FF:FF:FF:FF:FF, or multicast groups permitted by its filtering configuration. Some NICs use approximate multicast filters, potentially accepting additional multicast frames for further filtering by the operating system.

Promiscuous mode allows a capture interface to accept frames regardless of their destination MAC address, subject to hardware and driver capabilities. It is not necessary for capturing traffic already addressed to the host. On a switched network, however, promiscuous mode does not bypass the switch's forwarding decisions: the NIC still receives only traffic delivered to its port.

The EtherType tells the parser how to interpret the payload. Here, 0x0800 indicates IPv4. The field's position, rather than the numerical value alone, determines its meaning. In the hexadecimal dump below in the above figure, the source MAC address begins with 08:00:27, the same first two bytes as the IPv4 EtherType. This illustrates why packet fields must be interpreted according to their offsets within the frame.

For globally administered MAC addresses, the first three bytes commonly identify an IEEE-assigned organizational prefix, often called an OUI. In this capture, 08:00:27 is associated with PCS Systemtechnik, commonly encountered with VirtualBox virtual NICs. The prefix c4:ad:34 should be checked against a current vendor-registration source before assigning it to a manufacturer. Locally administered or randomized MAC addresses may not have a meaningful vendor association. In all cases, vendor-prefix information provides an investigative lead, not proof of a device's identity, because MAC addresses can be changed or spoofed.

By default, tcpdump decodes network-layer and higher-layer protocols, including certain non-IP protocols such as ARP, but does not ordinarily print the Ethernet header in its standard packet summary. This is a natural result of the tool being designed for analyzing TCP/IP, not Ethernet. The -e option displays the link-layer header in parsed form, including MAC addresses, protocol type, and packet length. The -x option prints packet data in hexadecimal without the link-layer header, while -X adds an ASCII column. The -xx and -XX options include the link-layer header in the hexadecimal output, with -XX also displaying ASCII.

For example, tcpdump -r magnitude_1hr.pcap -n -c 1 -xx  displayed the beginning of a captured Ethernet frame as c4ad 34d3 cc33 0800 273e 9312 0800. These 14 bytes represent the destination MAC address (c4:ad:34:d3:cc:33), source MAC address (08:00:27:3e:93:12), and EtherType (0x0800 for IPv4). This is the link-layer data exposed to the capture library, ordinarily without the physical-layer preamble, Start Frame Delimiter, or FCS.

Checksum anomalies must be interpreted carefully. An apparently invalid TCP or UDP checksum in a capture taken on the sending host may result from checksum offload, because the NIC can calculate the final checksum after the packet has been exposed to the capture mechanism. However, an IPv4 header checksum of 0x0000 should not automatically be attributed to checksum offload. Verify the actual field and header contents before drawing a conclusion.

Taken together, the short frame and oversized packet make a host-side capture affected by NIC or operating-system processing a plausible explanation. To establish this more confidently, examine the capture metadata, capture interface, checksum fields, and enabled offload features, and compare the observations with an independent capture from a TAP or appropriately configured switch mirror port.

VLAN tagging extends the standard Ethernet frame header. A VLAN is a logical Layer 2 broadcast domain, and IEEE 802.1Q allows multiple VLANs to share a physical link, commonly a trunk. The 802.1Q tag adds four bytes between the source MAC address and the original EtherType field. The tag begins with a 2-byte Tag Protocol Identifier (TPID), commonly 0x8100 for an IEEE 802.1Q customer VLAN tag. It is followed by a 2-byte Tag Control Information (TCI) field containing a 3-bit Priority Code Point (PCP), a 1-bit Drop Eligible Indicator (DEI), and a 12-bit VLAN Identifier (VID). VIDs 1–4094 are available for VLAN identification; VID 0 represents a priority-tagged frame without a VLAN ID assignment, while VID 4095 is reserved. The original EtherType follows the tag, identifying the encapsulated protocol as it would in an untagged frame.

The maximum conventional Ethernet frame size increases from 1518 bytes to 1522 bytes when one 802.1Q tag is present. These figures include the 4-byte Frame Check Sequence (FCS), but exclude the preamble and Start Frame Delimiter (SFD). The standard 1500-byte payload limit remains unchanged. A transmitting device must produce a valid FCS for the frame as transmitted, including its VLAN tag; when a device inserts or removes a tag, the resulting frame must have a valid FCS. Placing the tag before the original EtherType lets VLAN-aware hardware identify the tag and process its fields before interpreting the encapsulated protocol. A device that does not recognize the TPID may discard or mishandle the frame rather than correctly process it as a VLAN-tagged Ethernet frame. The fixed tag location also supports efficient hardware parsing.

Several tagging and encapsulation variants exist. IEEE 802.1ad, commonly called QinQ, supports stacked VLAN tags, often using 0x88A8 as the outer service-tag TPID and 0x8100 for the inner customer tag. Some equipment also uses TPIDs such as 0x9100 or 0x9200 by convention. With two four-byte tags, a frame carrying a standard 1500-byte payload can reach 1526 bytes including the FCS, assuming no other encapsulation. Equipment may support larger frames.

Cisco's legacy Inter-Switch Link (ISL) encapsulation wraps the original Ethernet frame in a 26-byte header and a 4-byte trailer. It is largely retired in favor of IEEE 802.1Q. ISL should not be confused with VLAN Trunking Protocol (VTP), a Cisco protocol used to distribute VLAN configuration information between switches; VTP does not add VLAN tags to individual Ethernet frames.

VLAN tags are commonly present on trunk links and in captures of mirrored trunk traffic. Access ports generally deliver untagged Ethernet frames to end devices, while traffic belonging to a trunk's native VLAN is commonly transmitted without a tag. However, switch configuration can change this behavior, and some switches support tagging the native VLAN. Consequently, an untagged frame in a capture may not provide enough information to determine its VLAN without consulting switch configuration, port context, or other network telemetry. 

The VLAN ID can be valuable forensic evidence. It can help establish which logical segment carried a frame, identify traffic observed on an unexpected VLAN, and support investigations of possible VLAN-hopping activity. Double-tagged frames are not inherently malicious, because stacked tags are legitimate in QinQ environments; their significance depends on the network design, ingress port, tag sequence, and switch configuration. Preserve VLAN information in the original capture archive. Confirm that the analysis tools in use correctly decode 802.1Q and any stacked tags. If a tool cannot process tagged traffic, work from a copy and document any transformation rather than modifying the evidentiary original.

Capture configuration can affect VLAN visibility. In tcpdump and libpcap, the vlan filter primitive changes the offsets used to interpret subsequent expressions. A filter such as ip or host may therefore fail to match tagged traffic when applied without accounting for the VLAN header. Filters for traffic that may be both tagged and untagged need to account for both forms, and stacked VLANs may require additional handling. 

Network Interface Card (NIC) VLAN offload can affect what appears in a host-side capture. Depending on the NIC, driver, operating system, and capture mechanism, a received VLAN tag may be removed from the packet data and exposed separately as metadata, or a transmit-side tag may be inserted after the capture point. As a result, the captured bytes may not precisely represent the frame observed on the wire. Investigators should document the capture interface and offload configuration and, when exact on-wire representation matters, corroborate host captures with a suitably configured network TAP or switch mirror.

MAC Addresses, IP Addresses, and Neighbor Resolution

The link layer is responsible for delivering frames across a local network link. In practice, this involves network interface hardware or virtual interfaces, device drivers, and the associated link technology. An Ethernet interface commonly uses a 48-bit MAC address, often called an EUI-48 address. Although a hardware interface may have a factory-assigned address, the active address can be changed by software. For example, Windows network drivers may support a NetworkAddress registry setting, while modern Wi-Fi clients may use per-network MAC randomization. Microsoft documents the NetworkAddress setting (HKLM\SYSTEM\CurrentControlSet\Control\Class\{4D36E972-E325-11CE-BFC1-08002BE10318}\<index>\) as a mechanism through which supported drivers can obtain a software-configured address. Consequently, a MAC address observed in a packet capture, ARP table, or neighbor cache identifies the address in use at that time; it does not necessarily identify the underlying hardware or a unique physical device.

Virtual network interfaces also have MAC addresses, often assigned by the hypervisor or virtualization platform. These addresses commonly persist in a virtual machine's configuration, but they can change when the VM is cloned, copied, migrated, or reconfigured. Incorrectly duplicated configurations can also result in MAC address conflicts. Certain MAC address prefixes are associated with common virtualization platforms—for example, 00:0C:29 and 00:50:56 with VMware, 00:15:5D with Hyper-V, 08:00:27 with VirtualBox, and 52:54:00 with QEMU/KVM. These prefixes are useful investigative clues, not conclusive proof: addresses can be manually configured, spoofed, or generated using different prefixes.

IP addresses operate at the internet layer and are assigned through mechanisms such as static configuration, DHCP, or IPv6 Stateless Address Autoconfiguration (SLAAC). IPv4 addresses are 32 bits long, while IPv6 addresses are 128 bits long. An IPv6 interface can have multiple addresses simultaneously, including link-local, stable, and temporary privacy addresses. Some IPv6 interface identifiers have historically been derived from a MAC address using modified EUI-64. For example, MAC address 08:00:27:3e:93:12 can produce the link-local address fe80::a00:27ff:fe3e:9312. However, many systems use other methods, including stable-opaque or randomized identifiers, so a MAC-derived identifier should not be assumed without verification.

IP-to-MAC mappings are time-dependent. Reconstructing which MAC device used an IP address at a particular time requires correlating time-stamped evidence, such as DHCP lease logs, ARP and IPv6 neighbor caches (which age out within minutes and should be captured early), and packet captures.  Switch forwarding tables and wireless controller records answer a different question: where on the network a given MAC was seen. Each source has its own retention period and limitations, so an address mapping should be treated as a time-bounded observation rather than a permanent identity. 

The internet layer addresses packets using IP addresses, while the link layer delivers frames using link-layer addresses. Before sending an IP packet, a host determines whether the destination is on-link according to its routing and address configuration. If the destination is on-link, the host resolves the destination's link-layer address. Otherwise, it resolves the address of the selected next-hop router, usually the default gateway. The IP packet's destination remains the intended IP destination even when the Ethernet frame is addressed to a router.

For IPv4 over Ethernet, the host checks its ARP cache and, if necessary, broadcasts an ARP request using EtherType 0x0806 and destination MAC FF:FF:FF:FF:FF:FF. A host that can answer for the target IPv4 address typically responds with an ARP reply. For IPv6, Neighbor Discovery uses ICMPv6 messages, including Neighbor Solicitation (NS) and Neighbor Advertisement (NA). Address resolution commonly uses the target's solicited-node multicast IPv6 address, which maps to an Ethernet multicast address beginning 33:33:FF. Neighbor Solicitation and Advertisement messages also participate in duplicate address detection and neighbor reachability procedures. During Duplicate Address Detection, the solicitation uses the unspecified IPv6 source address (::); a response indicating that the tentative address is already in use prevents the host from assigning that address. Once the next-hop link-layer address is known, the host constructs a frame with its outgoing interface's active MAC address as the source and the next hop's MAC address as the destination. This is a per-link operation: the Ethernet header is not carried unchanged across an IP router.

The first three bytes of many globally administered MAC addresses correspond to an Organizationally Unique Identifier (OUI), associated with an IEEE Registration Authority assignment. For example, a vendor lookup may associate a prefix with a particular organization, but the registrant is not necessarily the brand of the finished device. IEEE allocates MAC address blocks in multiple sizes, including MA-L, MA-M, and MA-S; the first three bytes alone may not identify the registrant for smaller allocations. Address assignments can also change, so vendor attribution should use a current registry and preserve the lookup date.

The locally administered bit is the second least significant bit of the first octet. When set, it indicates that the address is locally administered rather than a universally assigned address. For example, 02 as the first octet has this bit set. For unicast addresses, a second hex digit of 2, 6, A, or E in the first octet indicates the bit is set (for example, 02:… or 52:54:00:…). Such addresses are common with randomized, virtual, and manually configured MAC addresses, but the bit alone does not establish why the address was chosen. Conversely, a globally administered-looking address is not proof that it is genuine or that it uniquely identifies a physical device.

MAC addresses are used for delivery within a local link or Layer 2 domain; routers do not forward Ethernet broadcasts such as ordinary ARP requests across routed interfaces. Proxy ARP is a related but distinct mechanism: a router can answer a local ARP request on behalf of another IP address, but it does not forward the original ARP broadcast into the remote network.

When an IP packet crosses a router, the router removes the incoming link-layer header and constructs a new header for the outgoing link. On Ethernet, the source MAC is the router's outgoing interface address, and the destination MAC is that of the next hop on that link—or the final host if it is directly connected. Ethernet switches ordinarily forward frames without rewriting their source and destination MAC addresses, although switching operations such as VLAN tagging can alter frame headers. Exceptions include Layer 3 switches, which route like routers; wireless bridges and repeaters and hypervisor bridged networking over Wi-Fi, which translate MAC addresses; and first-hop redundancy protocols, which present a virtual gateway MAC (VRRP 00:00:5E:00:01:xx, HSRPv1 00:00:0C:07:AC:xx) that can move between physical routers, so an unchanged gateway MAC does not guarantee the same device.

For forensic analysis, a capture taken on a remote routed link therefore normally cannot reveal the original host's MAC address from the Ethernet source field. The original address may be recorded elsewhere, such as in DHCP logs, wireless association records, or a packet field that explicitly carries link-layer information. Such evidence must be interpreted in context: for example, an EUI-64-derived IPv6 identifier may expose bits associated with a MAC address, but it does not prove that the address is still in use or that the same physical device generated the packet.

To deliver an IP packet over Ethernet, the sender must determine the destination MAC address for the frame. This address belongs to the next hop on the local link, not necessarily the packet's final destination. Some traffic requires no address-resolution exchange: IPv4 multicast addresses map algorithmically to Ethernet multicast addresses using the prefix 01:00:5E and the low-order 23 bits of the IPv4 group address, while the IPv4 limited-broadcast address maps to FF:FF:FF:FF:FF:FF. Because the mapping preserves only 23 of the 28 variable bits in an IPv4 multicast address, multiple multicast groups can map to the same Ethernet MAC address. Point-to-point technologies such as PPP do not use Ethernet MAC addressing. For unicast traffic over Ethernet, IPv4 uses Address Resolution Protocol (ARP) to resolve the next hop's MAC address, while IPv6 uses Neighbor Discovery Protocol (NDP).

Before transmitting, the host consults its routing table to determine how to reach the destination. In a typical IPv4 configuration, an interface's address and subnet mask establish a connected route. If the destination falls within that connected network, the host can send directly to the destination and resolve its MAC address. Otherwise, the best-matching route identifies a next hop, usually a router, whose MAC address must be resolved. The routing table is authoritative: static routes, more-specific routes, policy routing, and other configuration can affect the decision, so a simple subnet-mask comparison does not cover every case.

IPv6 follows the same general routing principle, but on-link determination is not based solely on the interface's configured prefix. A prefix advertised as on-link in a Router Advertisement can establish that destinations within it are reachable directly, while static routes and other configuration can also affect routing decisions. Link-local destinations are restricted to their local link and cannot be reached through an ordinary router. Hosts commonly learn IPv4 default gateways through static configuration or DHCP. IPv6 hosts commonly learn default routers through Router Advertisements. ICMP redirects can, under appropriate conditions, inform a host of a potentially better next hop, although hosts may ignore redirects depending on their configuration and security policy.

For IPv4 unicast traffic over Ethernet, the host checks its ARP cache first. If no usable mapping exists, it broadcasts an ARP request on the local link. A host that owns the requested IPv4 address will typically respond with an ARP reply, usually sent by unicast to the requester. The sender can then construct the Ethernet frame with its active MAC address as the source and the resolved next-hop MAC address as the destination. The IP packet retains its original source and destination IP addresses.

For off-subnet traffic, the Ethernet destination is therefore typically the default gateway's MAC address, even though the IP destination identifies a remote host. In a capture taken on the local segment, many different remote destination IP addresses can consequently appear in frames with the same destination MAC address. This is normal behavior, not inherently suspicious. Unexpected destination MAC addresses may indicate multiple next hops, a directly connected destination, a routing or configuration change, or possible address-resolution manipulation. Investigators should corroborate such observations with routing tables, ARP caches, switch forwarding tables, and the capture point's network topology.

At each routed hop, the router examines the packet's destination IP address and consults its routing table. If the selected next hop is on a directly connected Ethernet network, the router resolves that next hop's MAC address, checking its neighbor or ARP cache first. The mapping may already be cached from previous traffic or address-resolution activity, but this is not guaranteed. If the selected next hop is another router, the frame is addressed to that router's MAC address rather than the final destination's MAC.

The router then constructs a new link-layer frame for the outgoing interface, using that interface's MAC address as the Ethernet source and the selected next hop's MAC address as the destination. For IPv4, it decrements the Time to Live (TTL) and updates the IPv4 header checksum. For IPv6, it decrements the Hop Limit; IPv6 has no IP-header checksum to update. The outgoing Ethernet frame also requires a valid FCS. The IP source and destination addresses ordinarily remain unchanged during routing, except when a function such as Network Address Translation (NAT) modifies them.

If a router cannot resolve the next hop's link-layer address, it may queue packets temporarily while attempting resolution. If resolution ultimately fails, the router discards the affected packets and may return an ICMP Destination Unreachable message, such as an IPv4 host-unreachable or network-unreachable indication, depending on the circumstances and implementation. Such messages, along with repeated resolution attempts and unanswered ARP requests, can help investigators reconstruct failed connections. However, the absence of an ICMP error does not prove that resolution succeeded, because routers and firewalls may suppress these messages.

Here we see ARP in action. Host WS-215 (10.1.17.215) wants to send an IP packet to HOST-02 (10.1.17.2). Its routing table indicates that the destination is on the same subnet, so WS-215 must address the Ethernet frame directly to HOST-02 and first obtain its MAC address. Finding no usable entry in its ARP cache, WS-215 broadcasts an ARP request in an Ethernet frame addressed to ff:ff:ff:ff:ff:ff with EtherType 0x0806. The switch floods the broadcast to eligible ports in the same VLAN, so hosts in that broadcast domain can receive it. The request asks which host owns 10.1.17.2 and includes WS-215's own MAC and IP addresses. HOST-02 can then respond with a unicast ARP reply and may cache the sender's mapping. Other hosts generally do not reply, although they may learn the sender's mapping from the request. To view the traffic, run:

tcpdump -r 2025-01-22-traffic-analysis-exercise.pcap -tne

The -r option reads from the capture file, -t suppresses timestamps, -n disables name resolution, and -e displays the link-layer header. The output shows the Ethernet source MAC (00:d0:b7:26:4a:74), the broadcast destination, EtherType ARP (0x0806), and a frame length of 60 bytes, excluding the FCS. The decoded request reads: “who-has 10.1.17.2 tell 10.1.17.215”.

The reported length 46 refers to the Ethernet payload length, including padding, rather than just the ARP message. An Ethernet/IPv4 ARP message is 28 bytes, so 18 bytes of padding bring the payload to the 46-byte minimum. Combined with the 14-byte Ethernet header, this produces a 60-byte frame before the FCS. A host-side capture can sometimes show only 42 bytes if it observes the frame before the NIC adds Ethernet padding; this depends on the capture point, operating system, driver, and hardware behavior.

For forensic analysis, compare the Ethernet source MAC with the ARP sender hardware address. Use a sufficiently detailed decode or inspect the ARP fields in Wireshark to make this comparison. The values normally match in a conventional ARP request, and a mismatch warrants investigation, but it is not proof of spoofing by itself. Interpret it alongside the capture point, encapsulation, and surrounding traffic. Likewise, one host broadcasting ARP requests for many sequential IP addresses may indicate address scanning or network discovery, but legitimate inventory and management tools can produce similar patterns.

ARP is specified in RFC 826. IPv6 does not use ARP; its equivalent address-resolution function is provided by the Neighbor Discovery Protocol (NDP), defined in RFC 4861. NDP uses ICMPv6 messages—including Neighbor Solicitation and Neighbor Advertisement—carried within IPv6 packets, and typically uses solicited-node multicast rather than Ethernet broadcast for address resolution.

When the broadcast request reaches the segment, interfaces on eligible ports receive it, but only HOST-02 (10.1.17.2) normally responds because the requested target IP address matches its own. HOST-02 sends a unicast ARP reply addressed to WS-215's MAC (00:d0:b7:26:4a:74), learned from the request, with its own MAC (00:24:e8:7f:09:5d) as the source. tcpdump decodes the response as “Reply 10.1.17.2 is-at 00:24:e8:7f:09:5d”. As with the request, a reported frame length of 60 bytes is consistent with an untagged Ethernet frame excluding the 4-byte FCS. The 46-byte payload includes the 28-byte ARP message and 18 bytes of padding.

Because the request contains WS-215's sender IP and hardware addresses, HOST-02 can learn the mapping and reply directly rather than broadcasting. Under the ARP processing described in RFC 826, a host updates an existing entry for the sender when processing the request, and the target can create an entry for the requester when preparing its reply. Actual caching behavior can vary by operating system and ARP policy. When WS-215 receives the reply, it can record the mapping 10.1.17.2 → 00:24:e8:7f:09:5d in its ARP cache. The packet that triggered resolution may have been queued while the host waited for a reply. Once resolution succeeds, WS-215 can transmit the pending packet. If resolution fails after the host's attempts, the packet is normally discarded, and the application may receive a local network error. TCP may later retransmit data if the connection remains viable, but ARP failure does not itself guarantee a transport-layer retransmission or an ICMP error. The resulting Ethernet frame uses WS-215's MAC as the source and HOST-02's MAC as the destination. Its encapsulated IP packet still has source 10.1.17.215 and destination 10.1.17.2. These IP addresses are unchanged by ARP resolution: ARP supplies the link-layer address needed to deliver the frame on the local network.

This brings us to the ARP cache, a table of recent IP-to-MAC mappings that avoids repeating address resolution for every packet. Entries are not necessarily permanent because mappings can legitimately change when an IP address is reassigned, a NIC is replaced, a virtual machine is cloned or reconfigured, a MAC address is changed or randomized, or a virtual gateway moves between devices during failover. Entries age and are refreshed according to implementation-specific policies. Some systems use a neighbor-reachability state machine in which an entry becomes stale after a period without confirmation; this is not the same as a universal fixed cache lifetime. Network devices may use different timers—for example, some Cisco IOS configurations have a default ARP cache timeout of four hours—but defaults vary by platform and configuration. Investigators should verify the actual timers and states for the system under examination rather than assuming a standard lifetime.

For forensic analysis, treat the ARP cache as volatile evidence and collect it early when authorized and operationally feasible. Useful commands include ip neigh on Linux, arp -a on Windows and other systems, Get-NetNeighbor in Windows PowerShell, and show ip arp on many network devices. These tools expose address mappings and, depending on the platform, their states. Linux and Windows may represent neighbor states differently; for example, Linux can report REACHABLE, STALE, DELAY, PROBE, and PERMANENT, while Windows uses its own state model.

Because ARP has no built-in authentication, a cache entry records the mapping the host currently accepts, not independently verified device identity. Forged ARP messages or gratuitous ARP announcements can alter mappings on systems that accept them. Investigative indicators include an unexpected MAC change for an IP address, conflicting claims for the same IP, or one MAC associated with many IP addresses. These observations require context: a single MAC associated with multiple IPs may be entirely legitimate for a router using proxy ARP, a virtual appliance, or another shared-address service.

This is an ARP request as decoded by Wireshark, with the Ethernet II and ARP layers expanded to show their fields. The frame is 60 bytes. Its Ethernet source MAC address is 00:0c:29:e1:84:e6, whose prefix 00:0c:29 is associated with VMware. This is consistent with a VMware virtual network interface, although the MAC prefix alone does not prove that the interface is virtual. The Ethernet destination is the broadcast address ff:ff:ff:ff:ff:ff, and the EtherType is 0x0806, identifying the payload as ARP.

The ARP message is 28 bytes. Together with the 14-byte Ethernet II header, this gives 42 bytes; 18 bytes of padding bring the frame to the Ethernet minimum of 60 bytes, excluding the 4-byte FCS: (14 + 28 + 18 = 60). The screenshot shows zero-valued padding. Padding is not necessarily zero in every capture, and host-side captures may omit the FCS. The ARP header begins with fields describing the address formats in use: hardware type 1 denotes Ethernet, protocol type 0x0800 denotes IPv4, hardware address size is 6 bytes, and protocol address size is 4 bytes. The opcode is a 2-byte field: 1 means request and 2 means reply.

The sender hardware and protocol addresses are 00:0c:29:e1:84:e6 and 10.42.85.10. These identify the requester and provide the information needed for a reply to be sent directly back to it. The target protocol address is 10.42.85.100, the IPv4 address whose hardware address the requester wants to discover. The target hardware address is all zeros. This field has a fixed length, but its value is not known to the requester; in an ARP request, receivers use the target protocol address to determine whether the request concerns them. It is important to distinguish the two destinations. The Ethernet destination is the broadcast address, so the frame is delivered across the local broadcast domain. The ARP target hardware address is 00:00:00:00:00:00, indicating that the requester has not supplied a target MAC address.

Hosts on the local broadcast domain receive the request, but the host configured to use 10.42.85.100 is normally the one expected to answer. In frame 56, the response arrives 10 microseconds after the request. Wireshark summarizes it as 10.42.85.100 is at 00:0c:29:95:cd:21. The reply is sent by unicast to the requester, providing the MAC address associated with 10.42.85.100. Other hosts processing ARP traffic may also update existing sender-address mappings, depending on their implementation and cache state; they should not be assumed to create or refresh entries identically in every operating system.

The packet list shows another exchange about 28.7 seconds later. In frame 109, 10.42.85.100 asks for the MAC address associated with 10.42.85.10, but this time the Ethernet destination is the specific MAC address 00:0c:29:e1:84:e6, rather than the broadcast address. Frame 110 supplies the answer. A unicast ARP request can be consistent with checking or refreshing a known neighbor mapping, but the packet list alone does not establish why the sender chose unicast or prove that a cache entry was nearing expiry. The behavior and timing depend on the operating system, network stack, and neighbor-cache implementation.

Frames 130 and 143 show a different activity: ARP probes from 00:0c:29:14:c2:95 for 10.42.85.115. Wireshark labels these requests as ARP probes, and their timestamps are approximately one second apart. A probe uses the unspecified sender IPv4 address 0.0.0.0 while testing whether a proposed address is already in use. This pattern is consistent with IPv4 address-conflict detection as described in RFC 5227. The two packets alone do not establish that the full probing sequence occurred or that the host subsequently adopted the address.

Frame lengths also deserve attention. The packets sent by 00:0c:29:e1:84:e6 appear as 60 bytes, while the reply from 00:0c:29:95:cd:21 appears as 42 bytes. A 42-byte capture is consistent with an observation point or capture mechanism that records the Ethernet header and ARP message before minimum-frame padding is added, or that omits padding from the captured representation. It does not, by itself, identify the capture host or demonstrate that the two systems handle padding differently. Before drawing conclusions, establish where the capture was taken and whether the capture path or NIC affects how frame lengths are reported.

The receiver selects the next protocol using the type value in the preceding Ethernet header. Here, EtherType 0x0806 selects ARP, while 0x0800 identifies IPv4 and 0x86DD identifies IPv6. Within ARP, the protocol type field 0x0800 specifies IPv4 as the protocol whose address is being resolved.

This is the ARP reply to the request examined previously. Host 10.42.85.100, with MAC address 00:0c:29:95:cd:21, responds to 10.42.85.10, whose MAC address is 00:0c:29:e1:84:e6. Wireshark’s Info column reads 10.42.85.100 is at 00:0c:29:95:cd:21, summarizing the IP-to-MAC mapping advertised by the reply.

The Ethernet header is addressed by unicast to the requester’s MAC address rather than to the broadcast address. Its EtherType remains 0x0806, identifying the payload as ARP. Within the ARP message, the 2-byte opcode is 2, indicating a reply; an opcode of 1 indicates a request.

The ARP address fields now reflect the response. The sender hardware address and sender protocol address contain the responder’s MAC and IPv4 addresses: 00:0c:29:95:cd:21 and 10.42.85.100. The target fields identify the requester: MAC 00:0c:29:e1:84:e6 and IP 10.42.85.10. In the original request, the target MAC field was zero-filled because the requester was trying to discover that address. The reply supplies the known MAC address.

The Ethernet source MAC matches the ARP sender hardware address. Checking that these fields agree is a useful validation step during packet analysis. A mismatch warrants closer inspection, but is not conclusive evidence of spoofing; the surrounding traffic, network topology, and any proxying or virtualization behavior should also be considered.

After processing the reply, 10.42.85.10 can use the advertised mapping to send IPv4 packets to 10.42.85.100 over the local network. The operating system will normally add or update the corresponding ARP cache entry, subject to its implementation and cache policy. The responder may already have learned the requester's mapping when it processed the original request, although this behavior also depends on the implementation and existing cache state.

Because the reply is unicast, other hosts on a switched Ethernet network do not normally receive it. The switch, however, processes the Ethernet header independently of the ARP exchange. It learns source MAC addresses and associates them with the ingress port and VLAN in its forwarding database, commonly called the Content Addressable Memory (CAM) table. This learning occurs without needing to inspect the ARP payload.

When frame 55 arrived, the switch could learn that 00:0c:29:e1:84:e6 was reachable through the port on which the request arrived. When the reply arrives, the switch can similarly learn the location of 00:0c:29:95:cd:21. It then consults its forwarding database to determine where to send the unicast reply. Entries generally age out after a period without relevant activity, although the timer and behavior depend on the switch and its configuration.

If a destination MAC address is not present in the forwarding database, a switch may flood the unknown-unicast frame to eligible ports in the relevant VLAN, excluding the ingress port. Broadcast and unknown-unicast flooding are distinct forwarding behaviors. For investigators, a switch's forwarding table can help associate a MAC address with a network port and, with suitable topology information, narrow down a device's likely connection point. However, the table is dynamic and does not directly map MAC addresses to IP addresses or establish a device's physical identity.

MAC flooding is a separate security concern. An attacker may attempt to overwhelm a switch's forwarding table with frames carrying numerous forged source MAC addresses. If the table cannot accommodate the entries, some destinations may become unknown and their traffic may be flooded more widely. The outcome depends on the switch's implementation and security controls, and flooding does not guarantee that a sniffer on another port will see the traffic. Port security and other protections can help mitigate this technique.

The captured frame lengths merit attention. The request in frame 55 is 60 bytes, while the reply is captured as 42 bytes. An ARP message occupies 28 bytes, so an untagged Ethernet header plus ARP message totals 42 bytes before padding. On a standard Ethernet link, the transmitted frame must meet the 60-byte minimum excluding the FCS; the reply would therefore normally include 18 bytes of padding on the wire. Some host-side capture paths record outgoing packets before the NIC adds that padding, or omit padding from the captured representation. The 42-byte length alone does not establish where the capture was taken, so confirm the capture point and capture mechanism before drawing conclusions.

Identifying an ARP Probe in Wireshark

This Wireshark example shows an ARP request with the Ethernet II and ARP layers expanded. It is a special type of request known as an ARP probe, which Wireshark identifies with the field [Is probe: True]. The frame is 60 bytes long. Its Ethernet header contains source MAC 00:0c:29:e1:84:e6, broadcast destination ff:ff:ff:ff:ff:ff, and EtherType 0x0806, indicating that the payload contains an ARP message. The source MAC prefix 00:0c:29 is associated with VMware, suggesting that the interface may be virtual; however, a MAC prefix alone is not conclusive evidence of virtualization.

The ARP message is 28 bytes long. In this capture, 18 bytes of padding bring the Ethernet payload to the minimum 46 bytes, giving a 60-byte frame before the 4-byte FCS: 14 bytes of Ethernet header + 28 bytes of ARP message + 18 bytes of padding. Ethernet padding is not universally required to contain zeros, although the bytes shown in this particular capture may be zero-valued. The ARP header begins with fields describing the address types and sizes. Hardware type 1 indicates Ethernet, protocol type 0x0800 indicates IPv4, hardware address size 6 specifies a six-byte MAC address, and protocol address size 4 specifies a four-byte IPv4 address. Opcode 1 identifies an ARP request; opcode 2 identifies an ARP reply.

The sender hardware address is 00:0c:29:e1:84:e6, while the sender protocol address is 0.0.0.0, the unspecified IPv4 address. The target hardware address is all zeros because the requester does not yet know the target's MAC address. The target protocol address is 10.42.85.10, the IPv4 address being checked. The zero sender IP is the key indicator that this is an ARP probe, as defined by RFC 5227. Before using an IPv4 address, a host can probe to determine whether another system is already using it. This process is used in IPv4 address-conflict detection, including when checking an address obtained through DHCP or configured statically. IPv4 link-local address selection also uses probing.

Under RFC 5227's default procedure, a host sends three probes, with an initial random delay of 0–1 seconds and randomized intervals of 1–2 seconds between probes. The zero sender address prevents the probe from advertising the tentative address as an established sender mapping. The two probes visible here, approximately one second apart, are consistent with this procedure, although the surrounding capture would be needed to establish the complete sequence. A potential conflict is detected if another host responds in a way that indicates the tentative address is already in use, or if another host sends a probe for the same address. The host must then follow the applicable conflict-handling procedure rather than simply assume the address is available. If no conflict is detected during probing, the host can proceed to use the address and typically broadcasts ARP announcements to make the mapping known to other hosts. Silence during the observed interval is evidence that no conflict was detected in that interval; it does not prove that no other host will use the address later.

An ordinary ARP request normally includes the sender's assigned IPv4 address. A gratuitous ARP announcement commonly uses the same IPv4 address in both the sender and target protocol address fields, although gratuitous ARP can take different packet forms. These packet types should not be confused: an ARP probe checks whether an address is already in use, whereas an announcement communicates that an address is in use.

The surrounding traffic provides additional context. Within microseconds of the first ARP probe, the capture shows IPv6 Duplicate Address Detection (DAD): a Neighbor Solicitation from source address :: checks the tentative link-local address fe80::2dcf:e660:be73:d220. The solicitation is sent to the corresponding solicited-node multicast address. The capture also shows a Router Solicitation sent to ff02::2 and MLDv2 listener reports sent to ff02::16. Together, these packets are consistent with an interface performing address configuration and multicast-listener discovery, as might occur during boot, resume, virtual-machine startup, or link reconfiguration. The packet burst alone cannot establish which event triggered it.

The IPv6 link-local address also illustrates why a MAC address should not be assumed to be embedded in every IPv6 address. Applying modified EUI-64 to MAC 00:0c:29:e1:84:e6 would produce the interface identifier 020c:29ff:fee1:84e6, corresponding to link-local address fe80::20c:29ff:fee1:84e6. The observed address, fe80::2dcf:e660:be73:d220, does not match that derivation. This is consistent with an interface identifier generated by another method, such as a stable-opaque or randomized mechanism, although the packet alone does not establish the exact method used.

For forensic purposes, an ARP probe reveals the IPv4 address that a host intends to use, even if DHCP lease logs are unavailable. However, the probe is not proof that the host ultimately acquired or used the address. Correlate it with later ARP announcements, ARP replies, packets sourced from the address, DHCP records, and other host or network evidence.

The capture illustrates protocol demultiplexing across header fields. The Ethernet EtherType 0x0806 tells the receiver to interpret the payload as ARP; 0x0800 identifies IPv4, and 0x86DD identifies IPv6. Within the ARP header, the protocol type 0x0800 specifies IPv4 as the protocol whose addresses are being resolved. These fields operate at different levels: the Ethernet EtherType identifies the immediate payload protocol, while the ARP protocol type identifies the network-layer address protocol involved in the resolution.

ARP Spoofing/Cache Poisoning

As the preceding packet analysis illustrates, ARP has no built-in mechanism for authenticating the identity of a sender. A host generally cannot verify from an ARP message alone that the sender is entitled to claim a particular IPv4 address. An attacker on the same Layer 2 network can exploit this weakness by sending forged ARP messages that associate a victim’s IP address, or the default gateway’s IP address, with an incorrect MAC address.

ARP also lacks transaction identifiers and sequence numbers that would allow a receiver to correlate a reply with a specific request. Although implementations maintain neighbor-cache state and may apply validation rules, many systems accept some unsolicited ARP updates. Depending on the operating system, cache state, and configuration, forged replies or requests may create or alter incorrect IP-to-MAC mappings.

Several characteristics make ARP spoofing possible. Requests are normally broadcast within the local broadcast domain, allowing hosts on that segment to observe them. However, ARP does not require a host to accept every reply, and cache-update behavior varies across implementations. An accepted forged update can replace a legitimate mapping, and the incorrect entry may remain until it expires or is corrected by subsequent traffic or another update. Attack tools may repeatedly send forged messages to maintain an incorrect mapping, although the required frequency depends on the target systems and their cache behavior.

One serious consequence is a man-in-the-middle attack. An attacker attempts to associate the gateway’s IP address with the attacker’s MAC address in the victim’s cache, while also associating the victim’s IP address with the attacker’s MAC address in the gateway’s cache. If the attacker forwards traffic between the two parties, communication may continue while packets pass through the attacker’s system. Depending on the protocols and protections in use, this position may expose unencrypted information or permit traffic manipulation. Encryption and authentication mechanisms such as TLS and SSH can protect application data against reading or modification, but they do not necessarily prevent traffic interception, connection disruption, or metadata observation. If traffic is not forwarded successfully, the attack can instead cause a denial of service. Traditional ARP spoofing requires access to the relevant Layer 2 broadcast domain.

Network switches can provide protections against these attacks. Cisco’s Dynamic ARP Inspection (DAI) is one example. On supported switches, DAI validates ARP packets received on untrusted interfaces against known IP-to-MAC bindings, commonly learned through DHCP snooping. Networks using statically configured IP addresses can use ARP access control lists where supported. Invalid packets can be dropped and logged. Trusted-interface settings require careful configuration because packets arriving on trusted interfaces may bypass these validation checks. DAI also needs to be enabled and correctly configured across the relevant network; its presence on one switch does not guarantee protection throughout a broadcast domain. Port security can complement DAI by limiting the MAC addresses permitted on a switch port, although it does not independently validate ARP address claims. Unmanaged switches generally do not offer enterprise-grade DAI functionality, so protection may need to come from other network controls and endpoint safeguards.

IPv6 Neighbor Discovery (ND), which performs functions including neighbor-address resolution, has related spoofing risks. The Secure Neighbor Discovery (SEND) extension provides cryptographic protections for certain ND exchanges, but deployment has remained limited. Other network controls, such as Router Advertisement Guard on supported switches, can help address specific IPv6 attacks, though they do not replace a comprehensive IPv6 security strategy.

For digital forensic investigators, several packet and network-state patterns can help identify possible ARP spoofing:

• One MAC address claiming multiple IP addresses: This may warrant investigation, especially if one of the addresses belongs to the default gateway. Routers, proxy ARP devices, and virtual appliances can legitimately serve multiple addresses.

• A changing gateway MAC address: A gateway’s IP-to-MAC mapping that changes unexpectedly may indicate spoofing, but failover, redundancy protocols, and legitimate network changes can produce similar observations.

• Conflicting claims for one IP address: Two different MAC addresses associated with the same IP address may indicate an address conflict or spoofing. Wireshark warnings are useful leads, not definitive verdicts.

• Unexpected or unsolicited ARP replies: These may indicate cache poisoning, but gratuitous ARP announcements and legitimate address changes can also generate unsolicited messages.

• Ethernet and ARP source-address disagreement: A mismatch between the Ethernet source MAC and the ARP sender hardware address deserves scrutiny. Validate the packet structure and consider the network architecture before drawing conclusions.

• Unexpected TTL changes: If traffic appears to pass through an additional Layer 3 forwarding hop, its IP TTL or IPv6 Hop Limit may differ from an established baseline. This is supporting evidence only; routing changes and other forwarding behavior can produce similar differences.

These indicators should be treated as leads rather than proof of an attack. Correlate packet captures with endpoint ARP caches, switch forwarding tables, DHCP snooping bindings, DHCP logs, router configuration, and relevant security logs. Preserve the original capture and collect volatile network-state evidence promptly, since cache entries and switch-table entries can expire or change. MAC vendor lookups may add context, but an OUI is not reliable proof of a device’s identity, particularly when addresses are virtualized, locally administered, randomized, or spoofed.

Suppose WS-215 (10.1.17.215) uses the router with 10.1.17.1 as its next hop for traffic leaving the local network and has no ARP cache entry for the gateway. In step 1, WS-215 broadcasts an ARP request: “Who has 10.1.17.1? Tell 10.1.17.215.” The Ethernet destination is ff:ff:ff:ff:ff:ff. Every host in the same broadcast domain, including the gateway and the malicious HOST-66 (10.1.17.66), can receive the request.

In step 2, HOST-66 observes the request. In step 3, it sends WS-215 a forged unicast ARP reply claiming that 10.1.17.1 maps to its own MAC address, 00:0c:29:7a:3e:5b. If WS-215 accepts the update, it may associate the gateway’s IP address with the attacker’s MAC address. The legitimate gateway may also reply, advertising its actual MAC address, 00:00:0c:01:9a:bd. The resulting cache state depends on the host’s ARP implementation, current entry state, and security controls; the diagram illustrates a possible outcome rather than a guaranteed race.

Linux has a neighbor-cache parameter called locktime, which helps prevent rapid changes between competing ARP mappings. Its commonly documented default is one second, but it should not be interpreted as a universal rule that the first reply always wins. Different systems and configurations can behave differently. An attacker may attempt to maintain a false mapping by sending further forged ARP messages. Whether an unsolicited reply changes a cache entry depends on the receiving implementation and its configuration, so repeated messages do not guarantee successful poisoning.

If WS-215 accepts the forged mapping, packets destined for off-subnet IP addresses are still addressed to their original IP destinations, but their Ethernet destination MAC is now the attacker’s MAC rather than the gateway’s. The attacker can therefore receive frames that WS-215 intended to send to the gateway. If traffic is not forwarded onward, connectivity may be disrupted. If the attacker forwards it, traffic may continue through the attacker’s machine. At this stage, poisoning WS-215’s cache affects the traffic WS-215 sends toward the gateway; intercepting the return direction generally requires an additional condition, such as poisoning the gateway’s mapping for WS-215.

For investigators, useful evidence includes multiple ARP messages claiming that 10.1.17.1 belongs to different MAC addresses, unexpected changes in WS-215’s ARP cache, and repeated announcements that conflict with the gateway’s verified interface address. Wireshark’s duplicate-address warnings can help identify these conflicts, but they are indicators rather than proof of malicious activity. Compare the packet capture with endpoint neighbor caches, switch forwarding tables, gateway configuration, and relevant network logs. Preserve volatile evidence promptly because cache and forwarding-table entries can change or expire.

With WS-215’s ARP cache poisoned, a packet sent to an address outside the local network—for example, 8.8.8.8—can leave in an Ethernet frame addressed to the attacker’s MAC (step 4). The IP destination remains unchanged: the packet still carries source 10.1.17.215 and destination 8.8.8.8, while its Ethernet header identifies 00:0c:29:7a:3e:5b as the destination MAC instead of the gateway’s actual MAC, 00:00:0c:01:9a:bd. To relay this traffic without interrupting the victim’s connectivity, HOST-66 must be configured to forward packets between the relevant interfaces or network paths. The attacker also needs to know the gateway’s actual MAC address, which may already be available in its ARP cache or can be learned through normal address resolution.

When HOST-66 receives the frame, it processes the Ethernet header and forwards the IP packet toward the gateway. For ordinary IPv4 forwarding, the router-like forwarding operation decrements the packet’s TTL and updates the IPv4 header checksum. HOST-66 constructs a new Ethernet frame, using its own MAC address as the source and the gateway’s MAC address as the destination (step 5): 00:0c:29:7a:3e:5b → 00:00:0c:01:9a:bd. The IP source and destination normally remain 10.1.17.215 and 8.8.8.8, assuming no NAT or other address-changing processing.

With traffic passing through the attacker, HOST-66 may observe the victim’s outbound communications and potentially modify traffic that lacks suitable cryptographic protection. Properly authenticated TLS connections and SSH sessions with verified host keys protect application content against silent interception and modification, although the attacker may still observe metadata, interrupt connections, or exploit users who disregard certificate or host-key warnings.

At this stage, the attacker may be able to intercept traffic sent from WS-215 toward the gateway, but the return path can remain unaffected. To redirect that direction as well, the attacker would attempt to poison the gateway’s ARP cache so that 10.1.17.215 maps to the attacker’s MAC address. The gateway must accept that mapping for the technique to work. It may already have a valid ARP entry for WS-215, or it may need to resolve the address through ARP. The attacker’s forwarded Ethernet frames teach the switch where the attacker’s source MAC is reachable; they do not, by themselves, teach the gateway that the victim’s IP address belongs to the attacker’s MAC. The gateway’s IP-to-MAC mapping is maintained separately in its ARP cache. If both poisoning attempts succeed and the attacker forwards traffic in both directions, communications between WS-215 and remote systems can pass through HOST-66. The attack’s success depends on the victim’s and gateway’s cache behavior, network topology, forwarding configuration, and any protective controls.

Forwarding may leave useful forensic evidence. If a capture point observes both sides of the forwarding path, it may show related packets twice: first in a frame from WS-215 to the attacker’s MAC, then in a new frame from the attacker’s MAC to the gateway’s MAC. Investigators can correlate these packets using their IP addresses, protocol fields, payloads, timestamps, IPv4 identification values where applicable, and TTL differences. For a normally forwarded IPv4 packet, the TTL is typically one lower after forwarding, and the header checksum changes accordingly. However, identical IP identification values or payloads are not guaranteed in every scenario, and the capture topology may prevent both copies from being visible.

Traceroute results may provide supporting evidence of a routing-path change, but a transparent intermediary does not necessarily appear as a separate hop. Likewise, asymmetric traffic or a one-sided poisoned cache can be a useful investigative clue, but neither proves ARP spoofing on its own. Correlate packet captures with WS-215’s ARP cache, the gateway’s neighbor table, the switch’s MAC forwarding table, and relevant endpoint or network logs. Collect this volatile evidence promptly, since cache entries and switch-table associations may change or expire.

ARP Spoof

The screenshot contains three Wireshark panes, each using a different display filter. The first, arp.dst.proto_ipv4 == 172.16.0.254, displays normal ARP requests asking “Who has 172.16.0.254?” (almost certainly the default gateway). Two hosts are asking: CIMSYS_33:44:55 and PcsCompu_21:b1:d0. The second, arp.src.proto_ipv4 == 172.16.0.254, ARP replies claiming ownership of 172.16.0.254. The green box shows legitimate replies from the real gateway (Cisco_f6:aa:30): “172.16.0.254 is at 00:1c:58:f6:aa:30”, while the red box shows spoofed replies from the attacker (PcsCompu_21:b1:d0): “172.16.0.254 is at 08:00:27:21:b1:d0” The third, eth.addr == 08:00:27:21:b1:d0, displays frames in which the specified MAC address appears as either the Ethernet source or destination.

The initial traffic follows a consistent ARP resolution pattern. In frames 4102 and 4103, at approximately 139.1 seconds, host 172.16.0.8 requests the MAC address associated with 172.16.0.254. The responding device advertises 00:1c:58:f6:aa:30. Similar requests from 172.16.0.5 receive replies advertising the same MAC address. At approximately 285.77 seconds, the observed pattern changes. Beginning with frame 4460, a different MAC address, 08:00:27:21:b1:d0, starts advertising itself as the owner of 172.16.0.254. The replies target multiple Micro-Star devices and recur in rapid succession. No corresponding requests are visible in the displayed rows, making these packets suspicious for unsolicited ARP activity.

The third pane provides additional evidence of possible bidirectional ARP poisoning. At approximately 922.39 seconds, the device using 08:00:27:21:b1:d0 continually claimed to be the gateway (172.16.0.254) and advertised several other IP addresses, including 172.16.0.4, 172.16.0.3, 172.16.0.2, and 172.16.0.1. This is consistent with an attempt to influence the gateway's ARP mappings for other hosts. However, the capture alone cannot establish that the gateway accepted these mappings. By repeatedly telling the network “I am 172.16.0.254”, it tries to make other machines send traffic destined for the gateway to itself instead. This is the classic first step of a MITM attack (followed by IP forwarding, SSL stripping, credential harvesting, etc.). The legitimate Cisco gateway is still correctly answering, which is why you see both the real and the fake replies. Frames 19158 and 19159 show an ARP request for 172.16.0.254 followed by a reply advertising 00:1c:58:f6:aa:30. This is consistent with the device seeking the legitimate gateway's MAC address, potentially to support traffic forwarding.

Forensic conclusion: The capture contains strong indicators of possible ARP spoofing: competing MAC-to-IP claims, repeated unsolicited-looking replies, and advertisements associating multiple IP addresses with one MAC. Arrival order alone cannot establish which response is genuine. Validate the gateway's configured interface MAC, DHCP records, known-device inventory, and switch MAC address table before attributing the activity to an attacker or declaring the attack confirmed.

How Do You Protect Against ARP Spoof Attacks?

ARP cache poisoning is simple in principle and can be highly disruptive. ARP has no built-in authentication, so a receiver cannot verify from the message alone whether a sender is authorized to claim a particular IPv4 address. ARP also has no transaction identifier or sequence number for correlating a reply with a specific request. Hosts maintain neighbor-cache state, however, and their handling of unsolicited replies, gratuitous ARP, and conflicting mappings varies by operating system and configuration. Some systems update existing entries based on ARP messages they observe, even when they were not the original requester; others apply additional restrictions. Legitimate uses of unsolicited ARP, including address announcements and failover, complicate efforts to reject all such traffic.

An ordinary Ethernet switch does not automatically prevent ARP poisoning. It forwards frames using a forwarding database, often implemented in content-addressable memory (CAM), that associates MAC addresses with VLANs and switch ports. The switch learns these associations primarily from the source MAC addresses of incoming frames, and dynamic entries generally age out after inactivity. Unlike a traditional hub, which repeats incoming signals across its ports, a switch normally forwards known unicast traffic only toward the appropriate port. But this forwarding behavior is not, by itself, ARP authentication. If poisoning causes a victim to address a frame to the attacker’s MAC address, the switch can legitimately deliver that frame to the attacker’s port.

MAC flooding targets the switch’s forwarding table rather than the victim’s ARP cache. An attacker sends frames carrying numerous forged source MAC addresses in an attempt to exhaust the table’s available capacity. Depending on the switch platform and its response to table exhaustion, frames for destinations that cannot be resolved in the forwarding database may be flooded to eligible ports within the VLAN. This can expose traffic to devices that would not normally receive it, but the outcome is not guaranteed: switches may have protections or behaviors that limit the effect. MAC flooding does not inherently redirect a victim’s IP traffic through the attacker, nor does it automatically enable traffic modification. ARP poisoning and MAC flooding are distinct techniques, although an attacker may attempt to combine them.

Defenses operate at several layers. Port security can restrict the number of MAC addresses learned on a port and may limit the impact of MAC flooding. Controls that suppress unknown-unicast flooding can reduce unnecessary traffic exposure, but must be configured carefully because legitimate frames may be flooded when their destinations have not yet been learned. Dynamic ARP Inspection (DAI), commonly used with DHCP snooping, validates ARP packets against known IP-to-MAC bindings and can drop packets that fail validation. Static ARP access control lists or other supported bindings may be needed for statically addressed systems. Static ARP entries for selected critical hosts can also help in specific environments, while 802.1X and port isolation can reduce opportunities for unauthorized devices to join or communicate across a network. The availability and behavior of these controls vary by vendor and configuration.

Traditional ARP spoofing generally requires access to the same Layer 2 broadcast domain as the victim, or another position from which the relevant Layer 2 traffic can be influenced. This is a meaningful constraint, but it does not eliminate the risk. A compromised workstation, rogue device, malicious guest on a bridged virtual network, or wireless client may already have that access. Attackers who establish a foothold on a network may also reach the relevant segment through lateral movement. On a network without effective protections, poisoning can occur quickly, although success depends on the target systems’ cache behavior and the surrounding network controls.

Both techniques can leave useful evidence. Potential indicators of MAC flooding include one port sourcing an unusually large number of distinct MAC addresses, switch logs reporting port-security violations or forwarding-table pressure, and an increase in unknown-unicast flooding. For ARP poisoning, investigators can look for unsolicited ARP replies, conflicting MAC addresses claiming the same IP, one MAC address claiming multiple IP addresses, and switch notifications that a MAC address has moved repeatedly between ports. Each indicator has legitimate explanations: multiple IPs per MAC may be normal for routers or virtual appliances, while MAC moves can occur during failover or virtual-machine migration.

Treat these patterns as investigative leads rather than conclusive proof. Correlate packet captures with switch forwarding tables, ARP or neighbor caches, DHCP snooping bindings, gateway configuration, and security logs. Collect relevant state promptly because dynamic cache entries and forwarding-table associations can change or expire.