I’m going to be interviewing some network engineers in the near future, so now is the time for me to brush up on the basics. Rather than take the “shortest path” I decided it might be fun to read RFC 791 – and what a classic this is.

Why has IP stood the test of time? My guess is that there are a few factors.

1. As mentioned in the preface, RFC 791 is actually based on six earlier versions of the ARPA Internet Protocol. So this is not creation ex nihilo but rather incremental refinement of some underlying ideas.
2. IP solves one problem and it solves it well. The authors are intentionally restrained, stating

The internet protocol is specifically limited in scope to provide the functions necessary to deliver a package of bits (an internet datagram) from a source to a destination over an interconnected system of networks. There are no mechanisms to augment end-to-end data reliability, flow control, sequencing, or other services commonly found in host-to-host protocols.

3. The “user interface” (i.e. the part of this protocol that systems programmers might interact with) is exceedingly simple. Although the details are OS dependent, this basically amounts to a pair of subroutines, send and receive.

With that said, the protocol still has more complexity than I expected. One challenge IP had to address is packet size differences across networks. Although the specification allows for packets up to 65kB, it only requires implementations to support packets as small as 68 bytes (60 bytes for the header and 8 for the data). This kind of flexibility was probably necessary, and to accommodate it IP supports something called fragmentation. Basically, IP describes how to break up or reassemble packets.

Fragmentation introduces significant complexity. The header has fields indicating how a fragment relates to its original packet. When a packet is fragmented, some fields of the original will copy to the first fragment but not the rest. Since IP uses checksums for error detection, fragmentation requires recomputing these. And there’s a whole page of the RFC detailing the complex (relative to the rest of the document) assembly procedure to recover a packet from its fragments.

In short, fragmentation is an engineering compromise to cope with networking realities of the time. The consensus seems to be that fragmentation is considered harmful, since if any of the fragments get dropped then the whole packet gets dropped. These days it looks like people try to avoid sending packets that exceed the maximum transmission unit (MTU) along the path, cf RFC 1191 and RFC 8899.

Anyways, I’ve said enough about fragmentation. To close this entry out, here’s something I didn’t know: the IP header has a 16 bit field for representation the security level of the packet, ranging from ‘Unclassified’ to ‘Top Secret’. There are eight additional levels reserved for future use – or so they claim….