Lesson Contents
The IPv4 header is a 20-60 byte structure that contains information fields about the packet at the beginning of every IPv4 packet. It acts like a shipping label that tells routers where the packet is destined and how to handle it.
Understanding these fields helps you troubleshoot network issues, configure Quality of Service (QoS), and diagnose fragmentation problems. In this lesson, we’ll walk through each field in the IPv4 header, explain what they are for and I’ll show you an example of what it looks like for an actual IPv4 packet. Let’s start with this picture:

This picture contains all fields you find in an IPv4 packet header.
Header Fields
Let’s walk through all these fields:
- Version: the first field tells us which IP version we are using, only IPv4 uses this header so you will always find decimal value 4 here.
- Header Length: this 4 bit field tells us the length of the IP header in 32 bit increments. The minimum length of an IP header is 20 bytes so with 32 bit increments, you would see value of 5 here. The maximum value we can create with 4 bits is 15 so with 32 bit increments, that would be a header length of 60 bytes. This field is also called the Internet Header Length (IHL).
- Type of Service: this is used for QoS (Quality of Service). There are 8 bits that we can use to mark the packet which we can use to give the packet a certain treatment. You can read more about this field in my IP precedence and DSCP lesson.
- Total Length: this 16-bit field indicates the entire size of the IP packet (header and data) in bytes. The minimum size is 20 bytes (if you have no data) and the maximum size is 65.535 bytes, that’s the highest value you can create with 16 bits.
- Identification: If the IP packet is fragmented then each fragmented packet will use the same 16 bit identification number to identify to which IP packet they belong to.
- IP Flags: These 3 bits are used for fragmentation:
- The first bit is always set to 0.
- The second bit is called the DF (Don’t Fragment) bit and indicates that this packet should not be fragmented.
- The third bit is called the MF (More Fragments) bit and is set on all fragmented packets except the last one.
- Fragment Offset: this 13 bit field specifies the position of the fragment in the original fragmented IP packet.
- Time to Live: Everytime an IP packet passes through a router, the time to live field is decremented by 1. Once it hits 0 the router will drop the packet and sends an ICMP time exceeded message to the sender. The time to live field has 8 bits and is used to prevent packets from looping around forever (if you have a routing loop).
- Protocol: this 8 bit field tells us which protocol is enapsulated in the IP packet, for example TCP has value 6 and UDP has value 17.
- Header Checksum: this 16 bit field is used to store a checksum of the header. The receiver can use the checksum to check if there are any errors in the header.
- Source Address: here you will find the 32 bit source IP address.
- Destination Address: and here’s the 32 bit destination IP address.
- IP Option: this field is not used often, is optional and has a variable length based on the options that were used. When you use this field, the value in the header length field will increase. An example of a possible option is “source route” where the sender requests for a certain routing path.
Wireshark Capture
Here is a Wireshark capture of an IPv4 packet where you can see how these fields are used:
Frame 3: Packet, 114 bytes on wire (912 bits), 114 bytes captured (912 bits) on interface eth1, id 0
Ethernet II, Src: aa:bb:cc:00:01:10 (aa:bb:cc:00:01:10), Dst: aa:bb:cc:00:02:10 (aa:bb:cc:00:02:10)
Internet Protocol Version 4, Src: 192.168.12.1, Dst: 192.168.12.2
0100 .... = Version: 4
.... 0101 = Header Length: 20 bytes (5)
Differentiated Services Field: 0x00 (DSCP: CS0, ECN: Not-ECT)
0000 00.. = Differentiated Services Codepoint: Default (0)
.... ..00 = Explicit Congestion Notification: Not ECN-Capable Transport (0)
Total Length: 100
Identification: 0x0000 (0)
000. .... = Flags: 0x0
0... .... = Reserved bit: Not set
.0.. .... = Don't fragment: Not set
..0. .... = More fragments: Not set
...0 0000 0000 0000 = Fragment Offset: 0
Time to Live: 255
Protocol: ICMP (1)
Header Checksum: 0x2245 [validation disabled]
[Header checksum status: Unverified]
Source Address: 192.168.12.1
Destination Address: 192.168.12.2
[Stream index: 0]
Internet Control Message Protocol
Let me explain what we see above:
- Version: 4 – Indicates this is an IPv4 packet (as opposed to IPv6)
- Differentiated Services Field: 0x00 – Used for Quality of Service (QoS); value 0x00 means default/best-effort delivery with no special priority.
- Total Length: 100 – The entire IP packet size is 100 bytes, including header and data.
- Flags: 0x0 – Control bits for fragmentation; all set to 0 means the packet is not fragmented, and fragmentation is allowed.
- Fragment Offset: 0 – Indicates the position of this fragment in the original packet; 0 means this is either the first fragment or the packet is not fragmented.
- Time to Live: 255 – Maximum number of hops (routers) the packet can pass through before being discarded; starts at 255.
- Protocol: ICMP (1) – Identifies the protocol used in the data portion of the packet; value 1 indicates ICMP (Internet Control Message Protocol), commonly used for ping.
- Header Checksum: 0x2245 – Error-checking value for the IP header to detect corruption during transmission.
- Source Address: 192.168.12.1 – The IP address of the device sending this packet.
- Destination Address: 192.168.12.2 – The IP address of the device that should receive this packet.
Hello Rene,
Could you please help on below queries
How network layer decides whether a packet to be fragmented or not?
Is it possible for a admin/application to enforce a fragmentation decision on IP packet?
Is there any relation between total length field and mtu?
Hi Ashok,
I wrote a post on this, I think it will answer your questions:
https://networklessons.com/ip-routing/pppoe-mtu-troubleshooting-cisco-ios
Rene
Thanks a lot Rene.. It was well explained there…
Hi Rene,
Why Header maximum length limited to 24 bytes ?
As per the theory, For 5 bit header field , maximum value is 15 so header length will be 4* 15 = 60 bytes.
Please correct me if it is limited to 24 bytes in production.
Regards,
SV
Hi SV,
Good question, some sources (for example Routing TCP/IP Volume 1) state that the maximum header length is 24 bytes so that 6 would be the maximum value. I can’t find any proof for this, it’s not in the RFC.
I just updated the lesson, with 4 bits, the highest value we can create is 15 so 15x32 = 480 bits (60 bytes)
Thanks for the input!
Rene