Summary

  • RFC 1001 and RFC 1002 separated name registration and discovery by the NetBIOS Name Server (NBNS) from group-datagram distribution by the NetBIOS Datagram Distribution Server (NBDD).
  • For P- and M-nodes, an NBDD query could describe a relay’s willingness, but the proposal allowed partial or refused distribution and supplied no confirmation that every intended recipient received a copy.

In a broadcast-oriented local network, a sender could address a group without first turning every group member into a separate destination. Carrying that service across routed networks raised a different question: who would know the members, and who would copy the datagram toward them? The March 1987 RFC 1001 and RFC 1002 answered those questions with two logical roles. The distinction is the story. A name server could identify or list owners; that did not make it the distributor.

The documents classify end nodes as B, P or M. A B-node uses a broadcast-area model. P-nodes use point-to-point infrastructure, while M-nodes combine aspects of both. In the P/M path, a datagram for a unique name goes directly to the address discovered for that name. A group name or the NetBIOS broadcast name takes another route: the sender unicasts the datagram to an NBDD, which is supposed to relay it to the nodes named by the destination. The sender no longer treats an IP broadcast as a universal delivery mechanism.

NBNS and NBDD are distinct entities in the architecture, even when one physical system implements both. If they are separate, RFC 1001 allows an implementation to exchange name information between them through a private protocol that the RFC does not specify. The arrangement creates a dependency: the relay must have enough information to associate the destination name with recipients, but the standard does not turn the private exchange into an interoperable, independently observable record.

A P/M-node sender may ask the NBDD whether it will distribute to a particular destination name before sending. A positive reply says the server will relay for that name. A negative reply enables a fallback: ask NBNS for the owners and send an individual unicast datagram to each listed owner. The check is optional. RFC 1002 says a node can send immediately, accepting the possibility that an NBDD will discard the datagram. These are alternative control paths, not two acknowledgments of the same completed delivery.

The critical limit appears after the query. RFC 1001 permits an NBDD to complete a request, complete it only in part, or refuse it. It says there is no feedback beyond the query that tells the sender whether forwarding occurred. A positive capability answer is therefore not a fanout receipt. The standards do not provide a per-recipient delivery record, and the article cannot infer one from the fact that a name was registered or a relay answered positively.

The multicast context also needs care. RFC 1001 describes an assumed environment in which an implementation could not count on Internet-wide broadcast or multicast support, and it includes an appendix sketching integration with Internet Group Multicasting. That is not proof that multicast had never been proposed: RFC 988, published in July 1986, had already proposed IP host multicast with different levels of support. The narrower point is that this NetBIOS design could not assume every participating network and node offered the needed multicast service.

RFC 1001 and RFC 1002 call themselves proposed standards. They describe a protocol design, not evidence that a named network deployed it, that implementations behaved uniformly, or that applications received every datagram. RFC 1001 also leaves B-node activity outside the view of the NBNS/NBDD support servers and does not specify those servers as bridges to B-nodes. These boundaries matter because the documents define responsibility more clearly than they define proof of an end-to-end outcome.

The scope also separates this article from RFC 1088, which covers deriving a NetBIOS name from an IP address and maintaining a local name table; mapping a name and distributing a group datagram answer different questions. The distinction remains useful beyond NetBIOS: discovering a set of destinations, authorizing a relay to act for that set, forwarding packets, and observing receipt are separate events. In this 1987 proposal, the first two were represented in control exchanges; the last two were not made visible to the original sender as a complete result.