Understanding IPv4 Packets: Structure, Fields, and Real-World Behavior

When you're debugging a flaky service or tracing latency across environments, sooner or later you end up staring at packets. And if you're working in most production systems today, those packets are still very likely IPv4 packets.

Let’s get straight into it by looking at what an IPv4 packet actually looks like on the wire.

The IPv4 Packet at a Glance

An IPv4 packet has two main parts:

• Header — metadata used for routing and delivery
• Payload — the actual data (e.g., TCP segment, UDP datagram)

The header is where most of the interesting behavior lives.

Basic Layout

1
2| Version | IHL | DSCP | Total Length |
3| Identification | Flags | Fragment Offset |
4| TTL | Protocol | Header Checksum |
5| Source IP Address |
6| Destination IP Address |
7| Options (optional) |
8| Data (Payload) |
9

Let’s break down the parts that actually matter in day-to-day engineering work.

Key IPv4 Header Fields Explained

1. Version

This is always 4 for IPv4. It sounds trivial, but it’s how network devices distinguish IPv4 from IPv6 packets instantly.

2. IHL (Internet Header Length)

Defines the size of the header in 32-bit words. Typical value is 5 (20 bytes), but it grows if options are present.

A common mistake: assuming headers are always 20 bytes. That breaks packet parsing in edge cases.

3. Total Length

This includes header + payload. Maximum size is 65,535 bytes, though in practice MTU limits keep it much smaller.

4. TTL (Time To Live)

This field prevents packets from looping forever.

• Each router decrements TTL by 1
• When it hits 0, the packet is dropped

This is exactly what tools like traceroute rely on.

TTL isn't about time — it's about hop count.

5. Protocol

This tells IPv4 what’s inside the payload:

• 6 → TCP
• 17 → UDP
• 1 → ICMP

Without this field, the OS wouldn’t know how to interpret the data portion.

6. Source and Destination IP

These are the addresses everyone recognizes. They determine where the packet comes from and where it’s going.

In cloud environments, these may be rewritten multiple times due to NAT or load balancers.

A Quick Real Example

Let’s say your service sends an HTTP request. Under the hood:

• Your app generates data
• TCP wraps it into a segment
• IPv4 wraps that segment into a packet
• Ethernet wraps it into a frame

That IPv4 packet might look like:

• Source IP: 10.0.1.5
• Destination IP: 172.217.10.46
• Protocol: TCP (6)
• TTL: 64

Every router along the path only cares about the header — not your application data.

Fragmentation: Where Things Get Messy

Here’s where IPv4 shows its age.

If a packet is larger than the network’s MTU (Maximum Transmission Unit), it gets fragmented.

How Fragmentation Works

• The packet is split into smaller pieces
• Each fragment gets its own header
• All fragments share the same Identification field
• Fragment Offset tells how to reassemble

Why It’s a Problem

• If one fragment is lost, the whole packet is useless
• Reassembly adds overhead
• Firewalls may drop fragments

This is why modern systems prefer Path MTU Discovery instead of relying on fragmentation.

Inspecting IPv4 Packets in Practice

When debugging networking issues, you’ll often inspect packets directly.

Using tcpdump

1
2tcpdump -i eth0 -n -v ip
3

This reveals:

• Source and destination IP
• TTL values
• Protocol type

Using Wireshark

Wireshark breaks down each field visually. You can expand the IPv4 header and see:

• Header length
• Flags (Don’t Fragment, More Fragments)
• Checksum validation

This is often the fastest way to understand strange network behavior.

Common Gotchas Developers Run Into

1. TTL Differences Across Systems

Different OSes use different default TTL values:

• Linux: 64
• Windows: 128

This can actually help identify traffic sources during debugging.

2. NAT Rewrites Headers

In containerized or cloud environments, the source IP you see inside your app might not be the real external IP.

Always consider:

• Load balancers
• Reverse proxies
• Kubernetes networking layers

3. Checksum Offloading Confusion

Sometimes packet captures show invalid checksums. That doesn’t always mean corruption.

Modern NICs often compute checksums in hardware, so packet capture tools may see incomplete data.

Why IPv4 Packets Still Matter in DevOps

Even with IPv6 adoption growing, IPv4 is everywhere:

• Most internal VPC networks still default to IPv4
• Many load balancers terminate IPv6 but forward IPv4
• Legacy systems rely entirely on IPv4

Understanding IPv4 packets helps you:

• Debug latency and routing issues
• Interpret packet captures
• Diagnose MTU and fragmentation problems
• Understand how services communicate under the hood

A Mental Model That Helps

Think of an IPv4 packet like a shipping box:

• The header is the label (addresses, instructions)
• The payload is the content inside
• Routers only read the label — never open the box

Once you internalize that, a lot of networking behavior starts to feel less mysterious.

And when something breaks, you know exactly where to look: not just “the network,” but a very specific set of fields inside a very specific structure.