Summary

  • RFC 966 proposed that a booting client could ask a stable host-group destination for help even when the servers behind it changed or were temporarily absent.
  • Its open-group rule let a nonmember send to the group. Group membership, forwarding state and successful delivery remained separate questions.

The address of a boot server is most important precisely when a diskless workstation has no other way to start. If that server is replaced, a client still holding its old address can be stranded before it can fetch new instructions. An operator may have to correct clients one by one. Broadcasting the request to every nearby host moves the cost to machines that cannot help. In December 1985, Steve Deering and David Cheriton proposed a different bargain in RFC 966: keep a group destination for the function, and let the servers behind it change. The surprising limit was explicit. The group could have no members. The design preserved a place to ask; it did not conjure an answer. This was a proposal for discussion, not a report of universal use.

The document framed multicast as both delivery and binding. Delivery is the obvious part: a packet addressed once may reach several recipients. Binding is more consequential for a new client. A well-known group destination could represent name servers, boot servers or another kind of service, while the machines able to answer could join or leave. The address was a point of coordination, not a fixed inventory of equipment. RFC 966 used a distributed-file example in which a client asked a group of servers for a file; the server that recognized the name could then reply directly. That was a proposed interaction, not a measured account of a deployed file service.

One host could join multiple groups, and the document even explored a machine reachable only through group addresses. It proposed permanent identifiers for durable logical meanings and transient addresses for short-lived groups. CreateGroup, JoinGroup and LeaveGroup described membership changes; a transient group would cease when its last member left. A permanent identifier therefore did not promise that a receiver was present. It held the name of a possible audience steady while the audience moved.

RFC 966 also chose open groups. A sender did not need to join before addressing a group. That choice made service discovery workable for a stranger: a workstation seeking a boot server should not have to become a boot server itself. The same proposal distinguished restricted membership through an access key. These are different controls. Permission to send an IP datagram to an open destination is not proof that the recipient will accept an application request, and permission to join a restricted group says nothing by itself about who may use the service.

The proposal was candid about its network costs. A gateway would need a record of which networks currently held group members; changes could propagate through other gateways. RFC 966 called the problem of keeping those records current a distributed-database problem it had not solved in the memo. It wanted repeated transmissions to avoid systematically missing a member, a property it called coverage, but described failure notification as a hint rather than a required receipt. A sent group packet was thus neither an exact list of all machines reached nor evidence that an application answered.

The next specifications narrowed the record. RFC 988 superseded RFC 966 in 1986 and explicitly said that a permanent group’s address, not its membership, was permanent. RFC 1112 repeated that distinction in 1989 and stated that best-effort multicast did not guarantee intact arrival to every member or a common order. The later texts do not make the 1985 proposal a universal deployment story. They show which conceptual split survived: stable destination, changing membership, and bounded delivery evidence.

This is why the group address mattered historically. It let the Internet describe what kind of receiver was sought without pretending to know in advance which machine would answer. But the convenience depended on live membership and forwarding information, and its packet-level promise stopped before authentication, service outcome or universal reachability.

Sources and limits

The primary documents are RFC 966, RFC 988, RFC 1112 and the earlier RFC 919 broadcasting proposal. They establish proposed and specified behavior, not a first live deployment, adoption rate, or observed service success.