IP Header Binary

The IPv4 Header Bit Layout

Every IPv4 packet that traverses the internet starts with a 20-byte (160-bit) header, and when I work with raw sockets or packet capture (pcap) files, this is the first thing I have to parse. The header is organized as a sequence of bitfields packed into 32-bit words, following RFC 791. Understanding this layout at the bit level is essential for anyone doing network programming, embedded networking, or security analysis.

The twelve fields of the standard IPv4 header occupy exactly 160 bits, arranged across five 32-bit rows. Here is the complete bit-level mapping:

I once wrote a packet parser from scratch to understand how IP headers work at the bit level. The version is the first 4 bits, the IHL is the next 4, and the total length field is 16 bits starting at offset 2. Parsing this structure with bit shifts gave me a deep appreciation for how efficiently IP headers are packed.

In practice, when I am debugging a captured packet or writing a parser, I visualize the header as five 32-bit words read left to right, most significant bit first. The first word packs Version, IHL, DSCP/ECN, and the first 8 bits of Total Length. Every field occupies a fixed position, which makes extraction straightforward with bitwise operations.

Version and IHL — The First Byte

I always start parsing an IPv4 header at the very first 8 bits. The high nibble (bits 0-3) is the IP version — for IPv4 this is always 0100 (decimal 4). The low nibble (bits 4-7) is the Internet Header Length (IHL), which tells me how many 32-bit words the header occupies. For a standard header with no options, IHL is 0101 (decimal 5, meaning 5 × 32 bits = 20 bytes).

When I write a raw packet parser, I extract these two fields with a single byte read and two bit shifts. The Version is (first_byte >> 4) & 0x0F and the IHL is first_byte & 0x0F. Verifying that Version equals 4 and IHL is at least 5 is the first sanity check in any robust parser.

Flags and Fragment Offset — Packed into 16 Bits

The second word of the header (bytes 4-7) packs three pieces of information into 16 bits: the Identification field (16 bits starting at offset 32), followed by a tricky 16-bit region that holds Flags (3 bits) and Fragment Offset (13 bits). The Flags field itself has three sub-bits: bit 0 is reserved (always 0), bit 1 is the Don't Fragment (DF) flag, and bit 2 is the More Fragments (MF) flag.

To extract Flags in code, I read byte 6 and shift right by 5 to align the three flag bits to the bottom: flags = byte6 >> 5. The Fragment Offset occupies the remaining 13 bits (bits 3-15 of the same byte plus the entire next byte). Fragment Offset is measured in 8-byte units, so the actual offset into the original datagram is fragment_offset * 8 bytes.

Parsing an IPv4 Header in Code

When I need to parse a raw IPv4 header from bytes — whether from a pcap file, a raw socket, or a captured network buffer — I use bitwise operations to extract each field. Here is a practical C implementation that demonstrates the exact bit positions:

// Parse fields from the first 20 bytes of an IPv4 header
// buf[0..19] contains the raw 20-byte header

uint8_t version  = (buf[0] >> 4) & 0x0F;       // bits 0-3
uint8_t ihl      = buf[0] & 0x0F;               // bits 4-7
uint8_t dscp_ecn = buf[1];                      // bits 8-15

uint16_t total_length = (buf[2] << 8) | buf[3]; // bits 16-31
uint16_t ident        = (buf[4] << 8) | buf[5]; // bits 32-47

uint8_t flags_raw = buf[6] >> 5;                // bits 48-50
uint8_t df_flag   = (flags_raw >> 1) & 1;       // Don't Fragment
uint8_t mf_flag   = flags_raw & 1;              // More Fragments

uint16_t frag_offset = ((buf[6] & 0x1F) << 8) | buf[7]; // bits 51-63

uint8_t  ttl       = buf[8];                     // bits 64-71
uint8_t  protocol  = buf[9];                     // bits 72-79
uint16_t checksum  = (buf[10] << 8) | buf[11];   // bits 80-95

uint32_t src_ip = (buf[12] << 24) | (buf[13] << 16) |
                  (buf[14] << 8)  | buf[15];      // bits 96-127

uint32_t dst_ip = (buf[16] << 24) | (buf[17] << 16) |
                  (buf[18] << 8)  | buf[19];      // bits 128-159

Notice the Fragment Offset extraction: I mask off the top 3 flag bits from byte 6 with 0x1F, shift left by 8, then OR in byte 7. This reconstructs the full 13-bit offset value, which in a non-fragmented packet will be 0. Every single field requires either masking, shifting, or both — which is why a solid understanding of bitwise operations is non-negotiable for network programmers.

The Protocol Field — Identifying the Payload

The Protocol field at byte 9 in the IPv4 header is a single 8-bit value that tells the receiving host which transport-layer protocol is encapsulated in the data payload. I rely on this field constantly when demultiplexing packets — it is the dispatch key that routes the payload to the correct handler.

In binary, Protocol = 6 for TCP means byte 9 is 0000 0110. When I see that value in a raw packet dump, I know the next layer starts with a TCP header, and I can proceed to parse the TCP source port, destination port, sequence number, and flags at their fixed offsets. Combined with the Total Length field, I can determine exactly how many bytes of TCP data follow.

Header Checksum — One's Complement Verification

The Header Checksum at bytes 10-11 protects the integrity of the IPv4 header itself (but not the payload). The algorithm is one's complement addition over all 16-bit words in the header. When I verify a checksum, I sum every 16-bit word — including the checksum field itself (which the sender set to zero during computation) — and then take the one's complement. If the result is 0x0000, the header is intact.

// Verify IPv4 Header Checksum (20-byte header with no options)
// Assume buf[0..19] contains the raw header

uint32_t sum = 0;
for (int i = 0; i < 20; i += 2) {
    sum += (buf[i] << 8) | buf[i+1];
}

// Fold 32-bit sum to 16 bits (one's complement addition)
while (sum >> 16) {
    sum = (sum & 0xFFFF) + (sum >> 16);
}

uint16_t computed_checksum = ~(uint16_t)sum;

if (computed_checksum == 0x0000) {
    // Header checksum is valid
}

This loop processes the 20-byte header as ten 16-bit words. The while-loop handles the end-around carry — a characteristic of one's complement arithmetic. If the computed checksum equals 0x0000 (meaning the sum of all words including the stored checksum is 0xFFFF after one's complement), the header passed validation. I use this exact algorithm in my packet inspection tools and it has never let me down.

Source and Destination Addresses — 32 Bits Each

The last 64 bits of the standard IPv4 header (bytes 12-19) hold the source and destination IP addresses, each occupying a full 32-bit word. These are stored in network byte order (big-endian), meaning the first byte is the most significant octet of the address. For example, the address 192.168.1.1 is stored as 0xC0A80101 in the header bytes.

To convert the four bytes into a readable dotted-quad string, I extract each octet with bitwise operations: octet 1 is (ip >> 24) & 0xFF, octet 2 is (ip >> 16) & 0xFF, octet 3 is (ip >> 8) & 0xFF, and octet 4 is ip & 0xFF. This is the same color-channel extraction pattern used in graphics programming — just applied to network addresses instead of pixel data.