Summary

  • RFC 1088, published as STD 48, carried IP datagrams inside NetBIOS datagrams and derived the receiving NetBIOS name mechanically from the IP address: IP.XX.XX.XX.XX.
  • The mechanism avoided a physical-address query for that mapping. It did not discover a route, prove who controlled an endpoint, support IP multicast, or establish that an IP datagram reached an application.

The temptation is to read the formula backwards. A visible, fixed name looks like a claim about a machine. It is not. RFC 1088 specifies a compatibility method for transmitting IP datagrams on a NetBIOS network. Its controlled act is encapsulation: the IP datagram becomes NetBIOS datagram data, and a recipient is selected by a NetBIOS name derived from the destination IP address.

That was a sensible way to make two local conventions meet. NetBIOS names could be sixteen bytes long. RFC 1088 reserved a recognizable form for IP applications: the prefix IP., followed by the four address bytes in ASCII hexadecimal. The derivation is deterministic. Given the address and this convention, the sender need not broadcast a question to learn a physical address. The RFC explicitly contrasts that fact with a physical-address query mechanism such as ARP.

The savings are narrow, which is why they are valuable. A query has been avoided; a table lookup has not become a proof. The resulting name does not say who owns an IP address, whether a host is alive, whether the network accepts the datagram, whether a router exists, or whether the upper layer accepts its contents. RFC 791 draws the enduring distinction: names, addresses and routes are different jobs. RFC 1088 performs one local mapping between an IP address and a NetBIOS delivery name. It does not perform the next job merely because its spelling is easy to inspect.

Two registrations, then a continuing receive

The implementation section makes the boundary operational rather than rhetorical. For each IP address, a host adds its derived IP.XX.XX.XX.XX name to the NetBIOS name table. It also adds the group name IP.FF.FF.FF.FF. It posts receive-datagram requests for both. When a datagram arrives at either name, the protocol stack processes it and posts another receive request. On shutdown, pending receives are cancelled and both names are deleted.

This is local state. It is not a discovery system that learns a hidden topology. It does not resemble the transparent-subnet machinery considered in RFC 950, where bridges may need to discover where hosts are and caches grow with that information. Nor does it turn the NetBIOS table into a global directory. It says which names a particular host should accept in this specified carrier.

That distinction also clarifies the relation to ARP. RFC 826 specifies a resolution mechanism for mapping protocol addresses to Ethernet addresses in its context. RFC 1088 does not replace ARP as a general theory of reachability. It says that for this NetBIOS naming convention, the IP address already yields the name needed for its datagram service. An engineer can admire that removal of one lookup without claiming that every lower-layer question has disappeared.

A broadcast name and an explicit omission

RFC 1088 gives broadcasts their own exact convention. Broadcast Internet addresses use the NetBIOS group name IP.FF.FF.FF.FF. The document then makes a useful negative statement: it makes no attempt to support IP multicast addresses through NetBIOS group names. That sentence is not a footnote. It tells an operator what the name-table trick does not generalize into.

The same discipline appears in the 512-byte maximum transmission unit. A NetBIOS datagram carries at most 512 bytes of data, so IP-over-NetBIOS has that MTU. Hosts communicating with such a host may need to reassemble fragments. The limit does not make fragmentation a failure of the mapping; it is a consequence of the carrier’s ceiling. It does mean that a trace must keep the separate facts separate: a derived destination name, a sent datagram, any fragments, and a reassembled IP datagram are not interchangeable observations.

The conditional router is not an inferred path

RFC 1088 says that a router capable of encapsulating IP in ordinary data-link protocols as well as NetBIOS datagrams permits these NetBIOS hosts to communicate with the wider Internet. The sentence is conditional, and its conditions matter. It describes what that capable router would make possible. It is not evidence that a particular router was deployed, that a particular host had global reachability, or that an address had an owner entitled to use a route.

This is the historical lesson in its cleanest form. The Internet grew by agreeing on small interfaces that could be implemented without resolving every other institutional or technical question. RFC 1088 made an address legible to one datagram service. It did not turn legibility into authority. The moment a monitoring system turns IP.XX.XX.XX.XX into “endpoint verified,” it has added a conclusion that the RFC carefully left outside its machinery.

Sources and limits of the record

The RFCs below establish the 1989 specification, its address/name convention, its stated limits and the relevant distinctions around IP, subnetting and ARP. They do not establish present deployment, a named host’s configuration, current reachability, ownership, identity, authorization, packet delivery or application success.