Summary

  • RFC 824 placed a Virtual Local Network between IP and the physical local network so Cronus software could depend on one stable interface while a different LAN was installed underneath.
  • That independence came with concrete work: specific, broadcast and multicast addressing, virtual-to-physical address maps, gateway routing and carefully limited delivery guarantees.

Suppose the local network is suddenly the wrong one. Perhaps it costs too much, performs badly or cannot stand the physical environment. In a badly coupled system, replacing the cable means rewriting the software that talks to it. In RFC 824, William I. MacGregor and Daniel C. Tappan offered Cronus a more useful answer: give the rest of the system a stable Virtual Local Network, or VLN, and make the physical network answer to that interface. IP could keep its coat on while the wiring changed shoes.

The August 1982 memo described a distributed operating system being designed at Bolt Beranek and Newman. Its diagram is almost a one-line argument: TCP and UDP above IP, IP above the VLN, and the physical local network below. Applications and other Cronus software did not have to address the peculiarities of every physical LAN directly. The designers named two goals, compatibility and substitutability. The first kept the facility compatible with DARPA’s IP and therefore with protocols such as TCP. The second let one physical local network be replaced by another if the VLN interface kept the same meaning.

That last condition does all the work. An interface is only stable when its promises are specific enough for a new implementation to honor. The RFC said the programming representation could vary from host to host; the functional capability could not. Replacing a physical LAN meant reimplementing the VLN interface on each Cronus host. The authors named cost, performance and ruggedness as reasons a cluster might want a different underlying network. They were describing an engineering choice with an invoice attached, not a magical plug that made every cable interchangeable.

The compatibility claim had a sharp edge too. The RFC insisted that IP itself needed no change or extension to run above the VLN. This was valuable because changing a widely used protocol could cost far more coordination than implementing a layer beneath it. In the memo’s design, a cluster of hosts sat on one physical local network. Internet gateways handled traffic beyond that cluster, and the VLN directed outward-bound datagrams to a gateway. The VLN counted as an Internet network with its own network number; the physical network underneath might carry the same number or a different one.

A stable face above the wire did not abolish routing below it.

Addressing shows why the word “virtual” was earned. A client could send to a specific host, to every host, or to a multicast group. The RFC’s local-address table assigned 0 through 1,023 to specific hosts, 1,024 through 65,534 to multicast, and 65,535 to broadcast. It recommended a class A or B Internet network to fit that whole range. Those were design choices for Cronus, not an invitation to apply the old table to today’s address allocations. The important move was that the VLN gave three delivery modes one client-facing vocabulary while the physical medium could implement them differently.

The Ethernet example makes the hidden labor visible. Each host maintained a VPMap: a table translating a 32-bit specific VLN host address into a 48-bit Ethernet address. Change a host’s physical address while preserving its VLN address and another host’s old mapping can become wrong. The RFC even discussed resetting the interface to rebuild dynamic tables. So the upper software could be spared the swap, but the layer doing the sparing had to keep a trustworthy account of where the hosts now lived. An abstraction that forgets to update its address book is a very polite way to lose the packet.

The memo also specified the size and quality of the promise. Datagrams of 576 octets or fewer could be transferred between any two VLN clients; a larger one might work for some pairs. The VLN itself did not fragment or reassemble Internet datagrams and did not process IP options. It did not promise reliable delivery or send negative acknowledgements for damaged or discarded packets. It did promise that a delivered datagram represented what was sent, and described each intended receiver getting a given datagram once or not at all.

Within a cluster, received datagrams formed a subsequence of sent datagrams: order could survive while some packets did not. The network was allowed to drop a letter, but it was not supposed to rearrange the ones it delivered.

That is the historical interest of Cronus’s VLN. The design drew a clean line between the client’s contract and the physical machinery, then spent pages spelling out what had to cross that line: address meaning, gateway choice, packet size and delivery behavior. The proposed swap was credible precisely because the memo made the costs of maintaining the illusion visible. The rest of the stack could ignore the new wiring only while the VLN did its unglamorous work underneath.