The IPv4 Protocol is used to transfer data packets across the network. These data packets contain a packet header in front of the actual data and contain information required for routing and delivering the packet across networks.
In this article, we have explained the IPv4 packet header with its diagram to help you understand its structure, fields, and size. You will learn how the IPv4 packet header works in providing smooth data routing and delivery.
To further deepen your knowledge about IP headers, you can check our networking courses online, where we have covered multiple protocols and technologies.
The IPv4 packet header is a 20-byte (maximum up to 60 bytes) section of an IPv4 packet that is put before the actual data and contains essential information for routing and processing the packet.
The IPv4 Packer header structure is built with 13 fields: Version, IHL (Internet Header Length), Type of Service, Total Length, Identification, Flags, Fragment Offset, Time to Live, Protocol, Header Checksum, Source Address, Destination Address, and Options.
Each field in the header contains specific information required for data transfer over IPv4 networks.
The IP packet contains the IPv4 packet header and data payload. The packet header helps in routing data to the correct destinations, and the data payload contains the actual information that has to be transmitted.
In this IPv4 packet, the header size ranges between 20 bytes to 60 bytes, depending on the options field, whereas the data payload size is variable. The total size of an IPv4 packet can not be more than 65,535 bytes.
Look at this IPv4 packet diagram, which shows the structure of the IPv4 packet header.
In the IPv4 Packer header format, the bits and bytes are organized in a specific way to ensure seamless communication across devices. Look at the above diagram, we see at the top it starts with 0 and ends with 31.
It represents a 32-bit value which has bits numbered from 0 (leftmost) to 31 (rightmost). The most significant bit (MSB) is on the left, and the least significant bit (LSB) is on the right.
A 32-bit value is divided into 4 bytes as follows
● Bits 0-7 (First Byte)
● Bits 8-15 (Second Byte)
● Bits 16-23 (Third Byte)
● Bits 24-31 (Fourth Byte)
These bytes are sent in order, starting with the most significant byte (bits 0-7). This is called Big Endian Byte Ordering. TCP/IP always uses Big Endian for consistency.
Some systems (like Intel-based devices) use Little Endian, where the least significant byte is sent first. These systems must convert data to Big Endian before sending it over the network.
Let's look at each IPv4 packet header field to understand their function.
It is a 4-bit field that tells the version of the Internet Protocol. Since only IPv4 uses this field in its header, it will always hold the decimal value 4.
The IPv4 Packer header length field tells how big the header is, but instead of using bytes, it uses 32-bit blocks called "words." Each word is 4 bytes. So if the field says "5," it means the header is 5 × 4 = 20 bytes long. The maximum is 15 words = 60 bytes.
It is an 8-bit field. In the initial implementations, it consists of 3-bit precedence, 4 TOS bits, and an unused bit, which should be 0. The 4 TOS bits are:
● Minimize Delay
● Maximize Throughput
● Maximize Reliability
● Minimize Monetary Cost
The Total Length field tells us how big the IP packet is (in bytes), which includes the header and data payload. By using the Total Length and another field called the Header Length, we can figure out where the header ends and where the actual data begins.
It is a 16-bit field, meaning the largest packet size it can handle is 65,535 bytes. If a packet is too big for the network, the packet gets broken into smaller pieces called fragments. Each fragment is sent separately but can be reassembled at the destination.
Some networks, like Ethernet, require a minimum packet size of 46 bytes. If the packet is too small, padding (extra space) is added to meet this requirement. The Total Length field ensures we know the actual size of the packet, even if padding is present. Without a Total Length field, the receiver wouldn’t know where the real data ends and the padding starts.
Imagine a Scenario
When you’re sending an IP datagram with a large file. If the file is too big for the network to handle in one piece, the IP layer breaks it into smaller packets. Each packet will have its own Total Length field to indicate its size. When all the packets arrive, they can be pieced together correctly because each part has clear instructions about its size.
On the other hand, if you’re sending something small, like a simple "Hello," the Total Length field ensures the receiver knows that only a small amount of data is expected, even if extra padding is added by the network.
Though it is possible to send a large datagram, most applications stick to smaller sizes to avoid fragmentation. For example
● UDP applications like DNS send packets under 576 bytes
● TCP automatically breaks data into smaller chunks to fit the network's requirements
Next, let's discuss how the IP header handles the fragmentation process using the three key fields.
When we send data over a network, it is often broken into packets called IP datagrams. Each datagram must fit within the size limits of the network it travels through. However, different networks have different size limits, called the Maximum Transmission Unit (MTU). If an IP datagram is larger than the MTU, it needs to be fragmented into smaller pieces to pass through. The receiver later reassembles these pieces into the original data.
Let's now understand IP header fields one by one, which help in handling the fragmentation process
The identification field of the IPv4 Packer header format is like a unique ID assigned to every IP datagram sent by a host.
● When a large IP datagram is fragmented, all fragments get the same Identification number.
● This helps the receiver understand which fragments belong to the same original datagram.
The Flags field has 3 bits, and each bit has a specific purpose:
● Bit 0: It is a Reserved bit and always be 0, which is not used.
● Bit 1: It is a Don’t Fragment (DF) bit. If this bit is set to 1, the router will not fragment the datagram. If the datagram is too large to pass through, it will simply be dropped, and the sender will get an error.
● Bit 2: It is a More Fragments (MF) bit. If this bit is set to 1, it means more fragments are coming. For all fragments except the last one, the MF bit = 1. For the last fragment, the MF bit = 0, signaling the end of the original datagram.
It is a 13-bit value field. When an IP datagram is fragmented, each packet has a Fragment Offset set, which tells the receiver where this fragment fits in the original datagram. The offset is measured in 8-byte blocks.
For example, if the first fragment starts at byte 0, its offset is 0, and if the second fragment starts at byte 1000, its offset is 125 (because 1000 ÷ 8 = 125). The Fragment Offset ensures that all pieces are put back together in the correct order at the receiver’s end.
Now, let's try to understand all three fields altogether from the above diagram. Let's say a source router R1 sends an IP datagram of 3000 bytes, and at R2, due to network limitations (like MTU), this original datagram is fragmented into 3 datagrams of 1000 bytes each. Each fragmented datagram will have the same identification number (not shown in the diagram above) so that the receiver can identify that all three fragments are a part of the same IP datagram.
The first and second fragments will have a More Fragments (MF) bit set to 1, while the last (third) fragment with have an MF bit of 0. The first fragment starts with byte 0, so the offset is 0, the second fragment starts with byte 1000, so the offset is 125 (as explained earlier), similarly, the third fragment starts with byte 2000, so the offset is 250. Using these values, the destination router R5 will be able to reassemble all three fragments and make an original IP datagram.
It is an 8-bit value in the format of an IPv4 Packer header. It sets the limit on the number of hops (routers) an IP datagram can pass through, meaning it defines the lifetime of the datagram.
The sender initiated the TTL value (32, 64, or 255 based on operating systems) in the IP header and it is then decremented by one at every hop it crosses. When it reaches 0 the datagram is discarded and an ICMP message is sent back to the sender. This prevents routing loops at layer 3 of the OSI layer model.
It is an 8-bit field in the IP header. It identifies the type of protocol that is encapsulated inside the IP packet. This helps the receiving device know which upper-layer protocol should process the data. The protocol has a specific number, for example:
● 6 for TCP (Transmission Control Protocol).
● 17 for UDP (User Datagram Protocol).
● 1 for ICMP (Internet Control Message Protocol).
When a packet arrives, the receiving device looks at this field to decide where to send the data next shown in diagram below.
The IP checksum is a mechanism used in the IP header to ensure that the data hasn't been corrupted during transmission. It is a 16-bit field and is used to calculate the checksum for the IP header only. It does not cover any data followed by the header. Other protocols like TCP and UDP have their own checksum fields for the header and data.
In checksum calculation, the initial checksum value is set to 0 so that it does not interfere with the calculations. The IP header is divided into 16-bit chunks or words. For example, if the header is 20 bytes, then it is divided into ten 16-bit words. These chunks are added together using a method called the one's complement sum. The one's complement of the total sum is stored in the checksum field.
When the receiver gets the datagram, it performs the same steps:
● Calculates the checksum based on the header values and compares it with the checksum in the received header.
● The sum of the calculated checksum and the received checksum is all ones (binary 1111...1111), the header is valid.
If not, the datagram is discarded.
When a router processes a packet, the only field it typically changes is the Time to Live (TTL) so instead of recalculating the entire checksum, the router adjusts the checksum incrementally to account for the change in the TTL field.
It contains a 32-bit value of the sender's IP address.
It contains a 32-bit value of the receiver IP address.
It is a variable-length list and always ends on a 32-bit boundary. Pad bytes with a value of 0 are added if necessary. This assures that the IP header is always a multiple of 32 bits (as required for the header length). The options are as follows
● Security and Handling Restrictions
● Record Route
● Timestamp
● Loose Source Route
● Strict Source Routing
The IPv4 datagram header enables efficient and reliable data transfer on the Internet. Some other benefits of the IPv4 Packer header are:
1. Packet Identification: The identification field helps in fragment reassembly, ensuring that packets split into smaller parts can be correctly reassembled at their destination.
2. Error Detection: The Header Checksum field checks for errors while data transfer, allowing devices to detect and discard corrupted packets during transmission.
3. Control Over Traffic: The Time to Live (TTL) field prevents packets from circulating indefinitely in the network by limiting the number of hops a packet can take before being discarded.
4. Quality of Service (QoS): The Type of Service (ToS) field allows for prioritization of certain traffic, which helps in managing network performance.
5. Fragmentation Management: The Flags and Fragment Offset fields facilitate the fragmentation of packets when necessary, allowing larger packets to be sent over networks with smaller maximum transmission units (MTUs).
The two major drawbacks of using IPv4 are:
The IPv4 Packer header does not guarantee the successful delivery of packets to their destination.
For example, when something goes wrong, such as a router going out of buffer, it simply discards the IP datagram and sends an ICMP message back to the source.
As shown in the diagram below, an IP datagram will not reach its destination; it depends on the reliability provided by the upper-layer TCP protocol.
The IP header does not keep any state information about datagrams, and these are taken care of independently. So, delivery of IP datagrams can sometimes be out of order.
As shown in the diagram below, IP datagrams are routed independently at each hop, and they do not keep any information about them, so at the destination router, datagrams are received out of order.
Understanding the IPv4 Packer header in detail will help you learn the basics of data transmission in Internet Protocol Version 4. In this article, we have explained the IPv4 datagram header format in easy language.
We have also learned about the 13 IPv4 Packer header fields along with their sizes and lengths. Each field of the IPv4 Packer header is unique and serves a purpose for IP working.
He is a senior solution network architect and currently working with one of the largest financial company. He has an impressive academic and training background. He has completed his B.Tech and MBA, which makes him both technically and managerial proficient. He has also completed more than 450 online and offline training courses, both in India and ...
More... | Author`s Bog | Book a Meeting#Explore latest news and articles
Share this post with others