Summary

  • RFC 791 defines Total Length as the complete IPv4 datagram in octets, including both its header and its data; IHL separately says where that data begins.
  • RFC 894 makes the architectural payoff explicit: Ethernet padding can extend beyond a short IP packet, but those padding octets are not part of the packet and are excluded from Total Length.

A short IPv4 datagram poses an unexpectedly revealing problem on Ethernet. The link cannot always transmit a frame whose data field ends exactly where the IP packet ends. RFC 894 requires an Ethernet data field of at least 46 octets, so a shorter IP datagram must be followed by zero padding. The receiver therefore sees a frame carrying more octets than the network-layer packet actually owns.

The IPv4 header settles the dispute from inside. Its 16-bit Total Length field declares the length of the datagram in octets, counting the IP header and the data together. RFC 894 is explicit that Ethernet's added padding is outside that length. The frame provides carriage; the datagram states its own boundary.

Two measurements define one payload

RFC 791 gives IPv4 two different length statements. Internet Header Length, or IHL, measures the header in 32-bit words. Its minimum value is five, making the ordinary option-free header 20 octets long. Total Length measures the whole datagram in octets. Taken together, the fields locate both ends of the data: it begins after IHL and extends until Total Length.

That division avoided making payload length a third independent field. Once the header length and complete datagram length are known, the data length follows by subtraction. If options enlarge the header, IHL moves the starting boundary while Total Length still marks the final one. Both measurements travel in the packet that they describe.

Counting the header in Total Length can initially seem less intuitive than counting only the data. Yet the complete measure is the portable one. A datagram may cross link technologies with different frame headers, trailers, minimum sizes and transmission limits. None of those wrappers changes what IPv4 considers its own bytes. The network layer can validate and process one self-delimited object rather than infer its extent from every enclosing medium.

The bytes that belonged to Ethernet

Ethernet shows why relying on the outer payload size would fail. RFC 894 says the IP header is followed immediately by IP data in the Ethernet data field. It then says that when the field would be shorter than 46 octets, zero padding should be added to meet Ethernet's minimum frame size. Crucially, the specification places those zeros outside the IP packet and outside IPv4 Total Length.

Suppose an option-free IPv4 datagram contains only a few data octets. IHL identifies the first data octet. Total Length identifies the final IP octet. Any remaining octets in the Ethernet data field are link padding, not part of the transport segment or other encapsulated protocol. Without that internal endpoint, the receiver would need medium-specific assumptions to decide which trailing zeros were meaningful.

The field does not reveal the physical frame's full size. It does not count Ethernet addresses, type fields, checks, preambles or other link machinery. Its authority is narrower and more useful: among the bytes delivered upward as an Ethernet payload, it states how many belong to this IPv4 datagram.

One ceiling, several practical limits

Sixteen bits allow Total Length to express values through 65,535 octets. RFC 791 immediately qualifies that arithmetic maximum, calling such long datagrams impractical for most hosts and networks. It requires destinations to be prepared to accept datagrams up to 576 octets, whether arriving whole or in fragments, and recommends sending larger ones only with assurance that the destination can accept them.

The distinction separates representation from delivery. A format can describe a datagram larger than a particular link can carry in one frame. RFC 894 sets an Ethernet-carried IP datagram maximum of 1,500 octets and notes that traffic leaving that Ethernet may encounter the broader Internet's smaller assumptions. The header's 65,535-octet vocabulary is therefore not a path MTU, a recommended packet size or a guarantee of receiver capacity.

This separation also explains why Total Length could remain stable while network media changed. The field states the object's size; other mechanisms decide whether the next link can carry that object as one unit. Conflating those questions would have bound IPv4's basic syntax to one link technology's envelope.

The same measure after fragmentation

Fragmentation changes the packet but preserves the measuring rule. RFC 791's procedure gives each fragment a header and sets that fragment's Total Length to its own header plus its fragment data. The value in a fragment is not the length of the original unfragmented datagram. It is the complete length of the IPv4 object currently being forwarded.

Other fields carry different responsibilities. Identification helps associate fragments from the same original datagram. Fragment Offset places a fragment's data within the reassembly space. More Fragments tells whether another piece follows. Total Length tells the receiver where this particular fragment ends. The mechanisms cooperate, but none can substitute for the others.

At reassembly, the last fragment's offset and data length help establish the original data extent. Here again, the useful quantity is recoverable because the fragment's own complete length and header length are known. Total Length supplies a consistent local boundary before the receiver reasons about the larger object to which the fragment belongs.

A boundary, not a proof

A declared length can be malformed. Packets can be truncated, implementations can contain bugs, and lower layers can report inconsistent data. The cited specifications do not measure how frequently such failures occurred or how modern offload hardware and capture tools expose them. Total Length gives a rule against which received bytes can be interpreted; it does not authenticate those bytes or guarantee that every declared octet arrived intact.

Nor does the field identify an application record. Its data may contain a transport header and only part of a higher-level message, or several higher-level units. The packet boundary belongs to IPv4. Transport and application protocols maintain their own boundaries and length rules where needed.

The durable design lesson is about authority between layers. Ethernet may add padding to satisfy its frame contract. A later link may impose a different transmission limit. Fragmentation may split one original datagram into several new IPv4 objects. Through each change, Total Length continues to state which octets the current IP packet claims, header included. IPv4 did not ask the frame to define the packet. It carried the boundary with it.

Sources