RFC 791: How Packets Cross Different Networks

RFC 791, published in September 1981, specified the format and behavior of version 4 of the Internet Protocol (IP). The document was prepared by the University of Southern California's Information Sciences Institute for the U.S. Defense Advanced Research Projects Agency's Internet programme, with Jon Postel as editor. It revised several earlier specifications; the entire idea of internetworking did not suddenly originate that month.

The practical environment included ARPANET, packet-radio networks and satellite networks, whose frame formats, addressing methods and maximum packet sizes differed. IP allowed end systems to place data in a common datagram and hand it to successive networks for transport. The inter-network devices, often called gateways in contemporary documents, extracted the datagram from its local-network encapsulation, selected the next destination, and repackaged it into a form the next network could carry.

References: [1] [4]

The RFC 791 header begins with a version number, followed by a header-length field indicating where the data starts; without options, the header is normally 20 bytes long. The total-length field covers both header and data, and source and destination addresses each occupy 32 bits. Addresses help the network layer direct delivery, but are neither people's names nor guarantees of a direct correspondence with a permanently fixed physical device.

The protocol field identifies the upper-layer protocol to which the data should be delivered, allowing the same IP network to carry different transport services. The time-to-live field limits how long a datagram remains in the network: the original text expresses it in seconds and requires a reduction of at least one at each processing step, preventing undeliverable packets from circulating indefinitely. The header checksum checks only the header and must be recalculated when relevant fields change. It neither verifies all application content nor provides cryptographic authentication against malicious alteration.

References: [1]

When crossing networks, a datagram may encounter a next segment with a smaller maximum packet size. RFC 791 permits fragmentation when necessary unless the sender has set the Don't Fragment flag. Each fragment carries an IP header and uses information such as identification, source and destination addresses and protocol to show which original datagram it belongs to. The fragment offset gives the data's position in the original, and the More Fragments flag helps the receiver identify the end.

Offsets are measured in units of eight bytes, so the data length of every fragment except the last must conform to that unit. For example, if a link accommodates at most 1,500 bytes and each fragment's header is 20 bytes, a fragment can carry at most 1,480 bytes of data. Reassembly is the destination host's responsibility; intermediate gateways do not have to collect every fragment before forwarding. Fragmentation resolves size differences but adds header overhead and reassembly work, and loss of one fragment may prevent delivery of the entire datagram.

References: [1]

IP treats each datagram independently and does not establish a connection guaranteeing order and arrival. Gateways select routes, but RFC 791 does not require all networks to use the same routing algorithm. Congestion, link failure or expiration of time to live can cause packets to be discarded. Receipt of some control error messages by the sender does not mean that every failure can be reported completely.

RFC 793, published in the same month, separately specified the Transmission Control Protocol (TCP), using sequence numbers, acknowledgments, retransmission and windows to provide applications with an ordered byte stream. A TCP segment can form the contents of an IP datagram, while IP need not understand whether the data is mail or a file. Layering confines the common functions essential to interconnection to a relatively small scope and lets applications choose transport methods according to their needs. Responsibility for reliability does not automatically disappear when an IP header is added.

References: [1] [2]

RFC 801, published in November 1981, translated the specifications into a transition plan. Host organizations had to implement IP and TCP and also make major services such as remote login, file transfer and email work over the new protocols. The old Network Control Program (NCP) environment and the new environment could not all switch simultaneously, so the plan provided for dual-protocol hosts and relay services to maintain communication among users at different stages. This involved operating systems, service programs and administration, far more than replacing a header format.

The plan targeted January 1983 for completing the conversion. The commonly cited ARPANET switchover of 1983 was a later adoption event and cannot replace RFC 791's September 1981 publication date. Nor did publication itself build the entire later public Internet. The document's lasting effect lay in establishing a common, deliberately limited network-layer agreement: networks retained their own technologies, while hosts and gateways could cooperate around a consistent datagram format to turn local connections into inter-network communication.

References: [3]