为何IP首部中IHL与版本字段的位置至关重要？

First, let's anchor this to the code you found in /usr/include/netinet/ip.h—it's easy to scratch your head at this conditional bitfield setup:

struct iphdr {
#if __BYTE_ORDER == __LITTLE_ENDIAN
    unsigned int ihl:4;
    unsigned int version:4;
#elif __BYTE_ORDER == __BIG_ENDIAN
    unsigned int version:4;
    unsigned int ihl:4;
#else
# error "Please fix <bits/endian.h>"
#endif
    ...

Great question—this is one of those low-level networking details that looks confusing at first, but clicks once you connect the dots between IP standards, endianness, and how C compilers handle bitfields. Let's break this down step by step:

First, the IP Standard Rule #

The IP header's very first byte is strictly defined in RFC 791 (for IPv4) as:

Top 4 bits: IP Version (e.g., 4 for IPv4, 6 for IPv6)
Bottom 4 bits: IHL (Internet Header Length), which tells how many 32-bit words make up the IP header (used to account for optional header fields)

When IP packets travel over the network, they're always sent in big-endian byte order (the "network byte order"), where the most significant bits/bytes come first.

Why the Endianness Check in ip.h? #

C bitfield behavior isn't standardized across compilers, but on most systems:

• Big-endian hosts (e.g., PowerPC, some embedded systems): Bitfields are allocated from the most significant bit (MSB) to least significant bit (LSB) of a byte. So declaring version:4; ihl:4; directly matches the network's big-endian byte structure—no swapping needed.
• Little-endian hosts (e.g., x86/x86_64, the architecture most of us use for Ubuntu): Bitfields are allocated from LSB to MSB. If we declared version:4; ihl:4; here, the compiler would map the first 4 bits of the byte to version (which would actually be the IHL bits from the network packet) and the last 4 bits to ihl (which would be the Version bits). That's backwards!

The #if __BYTE_ORDER check fixes this: on little-endian systems, it swaps the bitfield order to ihl:4; version:4;, ensuring that when we read the network's big-endian byte, we still get the correct Version and IHL values.

Why This Field Order Is Critical #

Mess up this order, and your IP stack breaks completely—here's why:

1. Version is the first thing network systems parse
   Every device (router, host, firewall) looks at the Version field first to know if it's dealing with IPv4 or IPv6 (or an obsolete version like IPv5). If you swap Version and IHL, the system will read the IHL value (usually 5 for a standard 20-byte IPv4 header) as the Version number—this is an invalid version, so the packet gets dropped immediately.

2. IHL defines where the payload starts
   The IHL tells the system how far into the packet the IP header ends and the transport layer (TCP/UDP) payload begins. If you read the Version value (4 for IPv4) as IHL, the system would calculate the header length as 4*4=16 bytes (instead of the correct 20), leading it to start parsing payload data 4 bytes early. This corrupts the entire transport layer header and any data inside.

3. Cross-platform compatibility
   That conditional code ensures the same struct iphdr works correctly on any architecture, whether it's big-endian or little-endian. Without it, programs using raw sockets would only work on one type of system and fail catastrophically on the other.

Quick Example #

Suppose a network packet's first byte is 0x45 (binary 01000101):

• Big-endian host: version gets 0100 (4, correct IPv4), ihl gets 0101 (5, correct header length).
• Little-endian host (with the swapped bitfields): ihl gets 0101 (5), version gets 0100 (4)—same correct result.
• If we didn't swap on little-endian: version would get 0101 (5, invalid), ihl would get 0100 (4, wrong length). Total failure.

内容的提问来源于stack exchange，提问作者user9583381