IPv4 Packet and Header
An IPv4 packet consists of a header and a payload. The header contains the source and destination addresses as well as control fields used for forwarding and fragmentation.
The payload can be part of a webpage, an email, or a video stream. The IPv4 header is metadata read by routers and hosts to deliver the packet to its intended destination.
Overall Structure of the IPv4 Header
The IPv4 header has a defined, standardized structure. Its standard size is 20 bytes (160 bits), though it can be larger if optional fields are used. The header is organized into multiple rows of 32 bits (4 bytes) each, which supports processing by network hardware. The mandatory fields carry addressing, lifetime, protocol, and fragmentation information.
The following fields are described in their order of appearance. The first 20 bytes (5 rows) are mandatory in every IPv4 packet.
Fields 1-4: Packet Identification
1. Version (Ver) - 4 bits
This first field identifies the version of the Internet Protocol being used. For every IPv4 packet, the field has the binary value 0100, which is the number 4 in decimal. This allows network devices to distinguish an IPv4 packet from an IPv6 packet, which would have a value of 6, or 0110.
2. Internet Header Length (IHL) - 4 bits
This field specifies the total length of the header itself. The header can have a variable size due to the optional "Options" field. This value is not measured in bytes. It is a 4-bit number that represents the number of 32-bit words (4-byte blocks) in the header.
- Minimum Value:
0101(decimal 5). This corresponds to a header length of bytes, the minimum possible size for a valid IPv4 header (without options). - Maximum Value:
1111(decimal 15). This corresponds to a header length of bytes.
A router uses this IHL value to know exactly where the header ends and the actual data payload begins.
3. Type of Service (ToS) / Differentiated Services Code Point (DSCP) - 8 bits
This field specifies how a packet should be handled according to priority and Quality of Service (QoS). It tells routers whether a packet is part of a time-sensitive application, such as a video call, or traffic with less time pressure, such as an email.
- Historically (ToS): The field was divided into sub-fields for "precedence," "delay," "throughput," and "reliability."
- Modern Use: The first 6 bits carry the Differentiated Services Code Point (DSCP), allowing traffic classification and prioritization. The final 2 bits carry Explicit Congestion Notification (ECN), which can mark congestion without dropping the packet. A router can give packets with a specific DSCP value, such as one used for Voice over IP, priority during congestion.
4. Total Packet Length - 16 bits
This 16-bit field specifies the total length of the entire IP packet (header + data payload) in bytes.
- Minimum Size: 20 bytes (for a packet with a 20-byte header and no data).
- Maximum Size: The maximum value of a 16-bit number is . Therefore, the maximum size of an IPv4 packet is 65,535 bytes.
However, most networks have a smaller , such as 1500 bytes for Ethernet. This field tells the destination host how much data it should expect to receive for this packet, especially if the packet was fragmented.
Fields 5-7: Handling Fragmentation
When a packet is larger than the MTU of a network it needs to traverse, it may be broken down into smaller pieces when DF is 0. With DF set to 1, the router discards the packet instead of fragmenting it. This process is called fragmentation, and the following three fields work together to manage it.Note: The detailed mechanics of fragmentation are a separate topic, but these fields provide the necessary control information.
5. Identification (ID) - 16 bits
If a packet is split into multiple fragments, each fragment is sent as its own packet. The Identification field contains a value shared by fragments of one datagram in the context of the source, destination, and protocol. The receiving host uses it with the fragment offset and MF flag to identify related pieces and reassemble the datagram. For an atomic datagram with DF set, MF clear, and a zero fragment offset, an implementation may use any ID value, including 0, under the updated ID specification.
6. Flags - 3 bits
These three one-bit flags control the fragmentation process:
- Bit 0: Reserved and must always be set to 0.
- Bit 1: Don't Fragment (DF): If this bit is set to 1, it forbids routers from fragmenting the packet. If the packet is too large for a network's MTU, the router discards it and sends the source an ICMP Destination Unreachable message indicating "fragmentation needed and DF set."
- Bit 2: More Fragments (MF): This flag acts as a signal for reassembly. If MF is set to 1, it means this is a fragment of a larger packet, and more fragments are yet to come. If it is set to 0, it indicates that this is either the last fragment of a series, or the packet was never fragmented in the first place.
7. Fragment Offset - 13 bits
When a packet is fragmented, the data is split into chunks. The Fragment Offset field tells the receiving host exactly where in the original packet's payload this particular fragment's data belongs. It is measured in units of 8-byte blocks. For example, if a fragment has an offset of 100, its data starts at byte in the original, unfragmented payload. This allows the destination host to reassemble the fragments in the correct order, even if they arrive out of sequence.
Fields 8-9: Packet Lifetime and Payload Type
8. Time To Live (TTL) - 8 bits
TTL limits a datagram's lifetime and prevents packets from looping endlessly through the network in case of a routing error.
- The sending host sets an initial TTL value (e.g., 64 or 128).
- Every router that processes the packet must decrease the TTL value by at least one.
- If a router receives a packet and, after decrementing, the TTL value becomes zero, the router discards the packet and sends an error message (ICMP "Time Exceeded") back to the source.
Without TTL, a single routing loop could consume network resources indefinitely and increase network load.
9. Protocol - 8 bits
The IP's job is to deliver the packet from a source host to a destination host. Once the packet arrives, the destination host's operating system needs to know which program or service should receive the data payload. The Protocol field specifies this. It contains a number that identifies the to which the data should be passed.
- A value of 6 indicates that the payload is a TCP segment.
- A value of 17 indicates a UDP datagram.
- A value of 1 indicates an ICMP message, used for control and error reporting.
Fields 10-12: Integrity and Addressing
10. Header Checksum - 16 bits
This field provides a basic form of error detection for the IP header. The sending host calculates a checksum based on the values in all header fields and places the result here. Each router along the path verifies the checksum.
- If a router finds a mismatch, it indicates that the header was corrupted during transmission, and the packet is discarded.
- The TTL field changes at every router, so the checksum must be recalculated by every router.
- Checksum Scope: The checksum only covers the header. It does not protect the data payload, which is the responsibility of higher-level protocols like TCP or UDP.
11. Source Address - 32 bits
This is the 32-bit IPv4 address of the host that originally sent the packet.
12. Destination Address - 32 bits
This is the 32-bit IPv4 address of the intended recipient. This field is the primary piece of information that routers use to make their forwarding decisions, guiding the packet hop-by-hop across the internet.
Final Fields: Options and the Actual Data
13. Options (if any) - Variable Length (0 to 40 bytes)
This is an optional, variable-length field that can be used for special handling, testing, or debugging purposes. Examples include options to record the route a packet takes or to add timestamps. Options occupy complete 32-bit words and are included in the length reported by IHL. In the modern internet, the Options field is rarely used. Processing it requires extra work from routers, which can slow down performance and move packets off the fast path. If options are present, the IHL field will have a value greater than 5.
14. Data (Payload) - Variable Length
Following the header (and any options) is the data carried by the packet. This payload is supplied by a higher-level protocol, such as TCP or UDP, and is not interpreted by the IP layer. Its length can be calculated by subtracting the header length (IHL * 4) from the Total Packet Length. The result includes only bytes belonging to this IPv4 datagram.