Networking

Every IP packet includes metadata that describes the data payload it is carrying to its destination. This metadata information has evolved over time as the Internet has matured. This article explains the contents and purpose of metadata found in IPv4 headers - the portion of an IP packet that precedes the data payload.

The first 32 bytes of an IPv4 packet consist of its header; information that describes the packet. What type of data it is, where it's going, where it came from, and a wealth of information that is normally only the concern of routers and firewalls.

Make sure you don't confuse this discussion of packet headers with connections, and particularly stateful connections. Packets have no awareness of connections. All IP packets are "stateless" by definition. It is routers and firewalls themselves that define connections, which are simply streams of related packets.

IPv4 headers consist of 32 8-bit bytes, known as octets. Each octet is a single 8-bit byte. There are 256 bits in total that make up the packet header. The chart below breaks down the structure of an IPv4 packet header into octets, bytes, bits, and bit offsets. This should help you visualize how the header is parsed by routers, firewalls, and hosts.

Version

The IP version. Always equal to 4 for IPv4 packets.

Internet Header Length (IHL)

The IPv4 header varies in size, with a minimum size of 160 bits and a maximum of 256 bits. This indicates the number of 32-bit sets of data (called words) in the header (5-8). Since this is a 4-bit value, it could theoretically contain a number between 0 and 15, but the only valid values for IPv4 are 5 through 8.

Differentiated Services Code Point (DSCP)

Originally defined as the type of service (ToS), this field specifies differentiated services (DiffServ) per RFC 2474 (updated by RFC 3168 and RFC 3260). New technologies are emerging that require real-time data streaming and therefore make use of the DSCP field. An example is Voice over IP (VoIP), which is used for interactive voice services.

Explicit Congestion Notification (ECN)

This field is defined in RFC 3168 and allows end-to-end notification of network congestion without dropping packets. ECN is an optional feature that is only used when both endpoints support it and are willing to use it. It is effective only when supported by the underlying network.

What Happened to ToS?

Type of Service (frequently referred to as ToS). Now obsolete.

ToS relates to the priority of a network packet relative to other network traffic. Sometimes used in advanced networks to incorporate traffic priority into the datagram of the traffic itself (versus traffic prioritization by other means, such as port, protocol, source/destination address). Traffic shaping and priority manipulation by ToS are beyond the scope of this document.

The subject of five (5) RFC documents published by The Internet Engineering Task Force (IETF), ToS was replaced by DSCP and ECN in order to align IPv4 with the IPv6 standard that eschewed ToS in favor of the latter two protocols. However, neither DSCP nor ECN replicates the prior behavior of ToS, which contributes to confusion within the IT community. ToS was originally intended to provide a method of assigning precedence to an IP packet. The higher the value, the higher the priority or precedence of the packet relative to other, lower priority packets.

ToS was officially sunset in late 1998 via RFC 2474, when the Differentiated Services Field (DSCP) was defined and applied to both IPv4 and IPv6 packet headers. Although deprecated a long time ago, it is still referenced by some network management tools and/or their documentation.

Total Length

A checksum value equal to the entire packet size, including header and data, in (8-bit) bytes. The minimum valid size is 20 bytes, which is equivalent to the minimum header size of 5x 32-bit words.

Identification

This is a unique ID assigned to a packet. It is only used for the purpose of re-assembling packets fragmented during the transition from origin to destination. Each fragmented packet includes an ID. This notifies the receiving host the packet is not complete, and the host will wait a period of time for the remainder of the packet to arrive. The ID is used to match and reassemble related fragments. The ID field is only used under these circumstances.

Once upon a time, the Identification field was applied by some hosts and routers during IPv4 transmissions to every packet. This caused substantial slowdowns of packet exchanges on certain types of connections. In 2013, RFC 6864 was released which deprecated this practice and clarified the purpose and bonafide uses of the ID field.

Flags

This has a dual purpose. First, the sending host may flag a packet with a "do not fragment" message that instructs routers not to fragment it. And second, if fragmentation is allowed (default behavior), then it is used by routers to inform the destination host whether or not the packet is a fragment or not.

Fragment Offset

The fragment offset. This informs routers and the destination host where the current fragmented packet's data payload aligns relative to the original (unfragmented) packet. Basically, it instructs them on how to put the data back together again in the original order.

Time To Live (TTL)

Time. Specified in seconds. Every packet has a limited period of time to exist. This practice prevents fragmented packets and slow packets from consuming resources indefinitely when the odds of completing the transmission diminish beyond a reasonable expectation. If the packet has not arrived at the destination host by the time the timer expires, it is dropped and an ICMP Time Exceeded advisory message is sent to the packet sender.

TTL has a dual purpose. It is also used as an informal system of tracking the number of hops. Each router in the chain of the packet travelling from source to destination reduces the TTL by one (1). Thus, in practice one should take this into consideration as very low TTL values could fail simply due to the number of hops. This practice improves security because after reducing the TTL value, a router must recalculate the Header Checksum prior to forwarding the packet.

Protocol

The IP protocol type (e.g. TCP), identified by a unique 8-bit number that correlates with the official list published by the Internet Assigned Numbers Authority (IANA). As of this writing (August 2019), there are 144 protocols (though not all of them are relevant to IPv4).

The most common protocols are TCP (6), UDP (17), and ICMP (1).

Header Checksum

As its name implies, this field is used for error detection of the header metadata. It is NOT correlated to the packet's datagram. Some protocols (e.g. TCP, UDP) incorporate checksum values inside the datagram, however many IP protocols do not. Regardless, it's up to the protocol and not the header to keep track of any datagram checksums.

Source Address

The originating or sending host. Note this can be altered via Network Address Translation (NAT) devices.

Destination Address

The receiving host. Note this can be altered via Network Address Translation (NAT) devices.

Options

This is the portion of the IPv4 header that causes it to vary in size. It's not used often. Note the IHL must correlate with this field.

References