IPv4 (Internet Protocol Version 4)

What it is (Definition)

IPv4, Internet Protocol version 4, is the core Layer 3 protocol that carries packets across networks using globally meaningful addresses. IPv4 defines how a packet is addressed, how routers forward it hop by hop, and how receivers identify the payload protocol (TCP, UDP, ICMP, and others).

A useful mental model is: Ethernet (L2) moves frames inside a local segment, while IPv4 (L3) moves packets across multiple segments and routers. IPv4 does not guarantee delivery, order, or timing by itself; it provides the addressing and forwarding layer that higher protocols depend on.

In practice, “IPv4 issues” often mean the packet cannot be routed to the right place, cannot survive the path (TTL/MTU problems), or is modified on the way (NAT). That is why IPv4 is central to troubleshooting: once you can reliably identify the source, destination, and path characteristics of a flow, higher-layer debugging becomes much faster.

IPv4 also defines how hosts interpret “where” a destination is. The same application request can either stay local (within a subnet) or traverse multiple routed segments depending on the destination address and routing policy. This is why IPv4 is often the first checkpoint in packet analysis: if addressing or routing assumptions are wrong, everything above it can look broken even when the application itself is healthy.

Where it sits in the stack (Layer & usage)

L3 — Network layer. IPv4 sits above link-layer framing (Ethernet, Wi-Fi, tunnels) and below transport protocols like TCP and UDP. Routers make forwarding decisions primarily based on the IPv4 destination address.

Below: L2 delivery to the next hop (e.g., Ethernet II frames, Wi-Fi frames, or tunnel encapsulation).
Above: TCP/UDP/ICMP and applications (DNS, HTTP, TLS) that rely on end-to-end addressing.
Where used: Nearly all enterprise and internet environments, including private RFC1918 networks plus NAT at edges.

IPv4 forwarding is hop-by-hop. Each router receives a packet, decrements its lifetime, and sends it toward the next hop. This is why link problems (ARP, VLAN, switching) and routing problems (wrong route, blackhole, asymmetric path) often show up as the same application symptom—yet they appear differently in packet captures.

Another useful distinction is “local delivery vs routed delivery.” If the destination is in the same subnet, the sender resolves a MAC address and sends directly on the local link. If the destination is not local, the sender targets the default gateway at L2, while the IP destination remains the remote host. This mismatch (L2 next hop vs L3 destination) is normal, but it can confuse beginners when reading captures.

Operationally, IPv4 is often paired with mechanisms that change how packets appear in captures: NAT rewrites addresses, tunnels add outer headers, and load balancers may terminate or re-originate flows. When debugging, it helps to decide whether you are observing the “inner flow” (end-to-end intent) or the “outer transport” (what the network is currently forwarding).

Header overview (Fields at a glance)

The IPv4 header carries addressing, fragmentation behavior, and a small set of fields that influence forwarding and diagnostics. In most captures you mainly interpret a handful of fields: source/destination, TTL, protocol, and fragmentation indicators.

Field	Size	Purpose	Common values / notes
Source / Destination IP	4 bytes / 4 bytes	Endpoint addressing	Private (RFC1918) or public; NAT may rewrite these
TTL	1 byte	Limits lifetime (hop count)	Decrements each router hop; used by traceroute
Protocol	1 byte	Next header / payload type	TCP, UDP, ICMP — detailed mapping belongs in Fields
Identification	2 bytes	Fragment association	Used when fragmentation occurs
Flags & Fragment Offset	variable	Fragmentation behavior	DF/MF and offset; detailed interpretation belongs in Fields
Header checksum	2 bytes	Header integrity	Recomputed at each hop when TTL changes

How it works (Typical flow)

A host selects the next hop using its routing table (local subnet vs default gateway).
The host encapsulates the IPv4 packet into an L2 frame addressed to that next hop (often via ARP on Ethernet).
Each router forwards the packet based on the destination IP, decrementing TTL along the way.
If a link MTU is too small and fragmentation is allowed, a packet may be fragmented; otherwise an ICMP error may appear.
The destination host demultiplexes the payload using the IPv4 Protocol field (to TCP/UDP/ICMP, etc.).

Forwarding: Determined by routing, not by MAC addresses.
Lifetime control: TTL prevents indefinite loops and enables path diagnostics.
Best-effort: Loss, reordering, and jitter are possible; reliability comes from higher layers if needed.

If you are reading a capture, a quick sanity check is: “Does the sender use the correct gateway, and is the destination address what we expect?” Many problems that look like application failures are simply packets being sent to the wrong place, not being routed at all, or being dropped due to policy.

How it looks in Wireshark

Display filter example:

ip

What you typically see:

Source and destination addresses are the first thing to confirm when debugging “wrong host” or NAT issues.
TTL changes across hops are a strong signal when tracing paths or spotting loops.
“Fragmented IP protocol” and reassembly notes appear when fragmentation is involved.

Quick read tip: When you suspect NAT, compare captures on the inside and outside of the NAT boundary.

For deeper inspection, you can narrow down traffic by address (for example, a single host) and then look at how the TTL and fragmentation-related fields behave across interfaces. Even without perfect topology knowledge, these patterns often reveal where “the path changes.”

A practical workflow is to start wide (filter `ip`), then progressively narrow: focus on a single conversation by selecting one source/destination pair, and finally inspect the header fields that “change on the path” such as TTL and fragmentation flags. This keeps you from overfitting too early to an application hypothesis and helps you locate whether the problem is local, routed, or policy-driven.

Common issues & troubleshooting hints

MTU problems and fragmentation symptoms

Symptom: Some connections work while others stall, especially for “larger” transfers. Users may report that small pings succeed but certain websites or VPN connections hang. Captures may show repeated retransmissions above IP without clear application progress.
Likely cause: A path MTU mismatch exists, and fragmentation is blocked or not handled as expected. If “don’t fragment” behavior is enforced and ICMP messages are filtered, endpoints may never discover the correct usable MTU.
How to confirm: Look for ICMP “fragmentation needed” style errors or evidence that packets exceed a link MTU along the path. If you see large packets leaving but not arriving (or repeated retries), MTU/fragmentation is a strong candidate.

Routing blackhole (packets disappear)

Symptom: Traffic leaves the sender but no replies return, and the failure persists across multiple applications. The sender may show repeated retries at TCP level, while Wireshark shows outbound packets without matching inbound responses.
Likely cause: A missing route, incorrect next hop, policy route, or ACL causes packets to be dropped somewhere in the path. Asymmetric routing can also cause replies to return via a different path and be blocked by stateful filtering.
How to confirm: Compare captures at different points (client vs gateway vs server side) if possible. If the packet is visible on one side but never appears downstream, the drop location is between those points. TTL patterns can also suggest loops or unexpected hops.

NAT side effects (unexpected IP/port changes)

Symptom: Applications fail only across network boundaries, or sessions break when moving between networks. Captures show that the “same” flow appears with different addressing on different interfaces, which can confuse correlation.
Likely cause: Network Address Translation rewrites source/destination information. Some protocols embed IP/port data inside payloads or assume stable addressing, and those assumptions can break without protocol-aware handling.
How to confirm: Capture on both sides of the NAT device and compare the 5-tuple (src/dst IP, src/dst port, protocol). If the payload matches but the addressing changes across the boundary, NAT is in the path and may be relevant to the failure.

Security notes (if relevant)

IPv4 itself does not provide encryption or strong authentication. Many security controls operate around it: segmentation with subnets/VLANs, filtering with firewalls, and encryption at higher layers (TLS, VPNs). IP spoofing, scanning, and reflection-style abuse rely on the fact that IP headers can be forged unless prevented by network policy.

From a capture perspective, security investigations often start with the same IPv4 basics: “Who is talking to whom, and via which path?” Unexpected source addresses, unusual TTL values, or traffic that appears only on one side of a boundary can indicate spoofing, misrouting, or asymmetric visibility. IPv4 does not prevent these by itself, so defense relies on filtering, segmentation, and validation at network edges.

Related pages (internal links)

Back to Dictionary Index
Key fields (IPv4 TTL, Flags/Fragmentation — Soon)
Related topics (Troubleshooting MTU, Routing blackholes — Soon)