Summary

  • RFC 947 describes a host-based forwarder and repeater that carried selected Cronus broadcasts between distant LANs while ordinary gateways carried the intervening traffic.
  • The authors avoided putting this feature into gateways or every Cronus kernel; their working host implementation exposed a substantial packet-filtering cost.

A message reaches the wrong edge of its network

Cronus could use a local broadcast to find a resource or gather the status of servers without first knowing which host held the answer. That was convenient inside one Ethernet. At the edge of the physical network, the convenience ended: a broadcast did not simply travel with the rest of the Internet traffic through a gateway. The resulting problem was narrower than a general failure of connectivity. Hosts on separate networks could communicate; a particular way of asking an unknown local recipient could not follow them.

Ken Lebowitz and David Mankins described their answer in RFC 947, published in June 1985. Cronus used both TCP and UDP, and its broadcasts often reached more machines than the application actually needed. The authors regarded multicast as a closer match for this selective audience, but said that some of their network implementations did not offer it. The initial Cronus utilities therefore used broadcast. Their experiment asked how to preserve that utility across more than one physical network without treating every gateway as a Cronus participant.

The forwarder listened on a host attached to the sending LAN. It selected broadcast UDP packets by specified ports or destination addresses and wrapped a matching packet in a message for a repeater on a distant LAN. A configuration file named the repeaters and could specify a different packet selection for each one. The forwarder attempted a TCP connection to each configured repeater and retried periodically after failure. At the far end, the repeater put the packet onto its LAN with that LAN's link-layer broadcast destination, while retaining the source address of the original packet.

The intervening gateways moved traffic between networks, but did not become broadcast repeaters themselves.

The configuration could also name a host that was not a repeater. In that case the forwarder changed the destination from broadcast to that host's address and sent a unicast datagram. This small option shows the real scope of the design. It was a selectively configured distribution service, not an instruction for all routers to propagate every local broadcast. The RFC reports a service built around Cronus needs, while noting that the mechanism could apply to other broadcast-based protocols.

Why the gateway stayed out

Putting the function in gateways was an explicit alternative. The authors rejected it for several reasons. Gateways would need tables of recipients and an extension to the gateway control protocol to keep those tables current. Selecting only useful messages might require knowledge higher in the protocol stack than a gateway had. A Cronus installation might depend on equipment from vendors that never implemented the feature. More revealingly, the people controlling the underlying gateways might be different from the people reconfiguring Cronus.

A convenient central location in a network diagram was not necessarily an available administrative location.

The Cronus kernel offered another apparent home. Yet placing the mechanism there would make all participating kernels know the addresses of their peers, limiting the flexibility of changing a system's composition. It could also tie the solution more tightly to Cronus. Host processes kept this distribution decision with the system that needed it. That placement is the article's historical hinge: the extension crossed network boundaries while its operating choices remained outside the shared gateway layer.

The authors knew that a rebroadcast packet could return to a forwarder and circulate. A forwarder therefore refused to connect to a repeater on its own LAN. It also declined to forward packets whose source address was outside the forwarder's LAN, a precaution against a loop spanning two LANs. Those were described feedback controls, not a claim of sender authentication or universal loop safety. Keeping the original source field required a special capability in BBN's TCP/IP implementation so a privileged process could transmit with another host's source address.

The visible source field told the receiver where the original datagram purported to come from; it did not by itself prove identity.

What the reported test can establish

The experience section records two Ethernets separated physically by two other LANs. Messages between them crossed at least two gateways. On a VAX running 4.2BSD UNIX with BBN networking software, separate forwarder and repeater processes had extended the broadcast domain for several months, and the authors said the arrangement worked well for their purposes. That is a bounded report of one configuration, not a count of deployments or a measure of general Internet adoption.

Success had a cost the authors did not hide. The user-level forwarder woke for every UDP packet arriving at the shared host, then rejected packets it did not need to relay. They considered moving filtering into the kernel while keeping configuration and rebroadcast in user code. They also planned to rehost the repeater on a dedicated microcomputer-based real-time system. RFC 947 records those as possible remedies, not completed outcomes.

RFC 919 had already warned that broadcast imposes work on every receiving host; RFC 922 described IP broadcast amid subnetting. The Cronus report adds a more particular lesson. Extending reach did not remove the need to decide which packets deserved to cross, who could configure that decision, and which machine paid to inspect them. Its evidence ends with the authors' experiment. Later multicast specifications, including RFC 1112, mark a different standards surface, not proof that this particular installation was replaced.

Sources