Summary

  • RFC 2097 made an end system ask a remote peer to add named NetBIOS identities to the peer network. A single negotiation could record success for some names and a concrete failure for others.
  • NBFCP also exposed the peer class, multicast pacing and priority, and whether every NBF datagram required a twelve-octet IEEE MAC header. These were operational terms of admission, not decoration around link-up.
  • An Opened state or Added=0 remained local evidence. Neither proved global uniqueness, authenticated identity, authorization, LAN-to-LAN reachability, complete delivery, later session success or security.

A remote-access link can be electrically alive, PPP can be past its Link Control Protocol, and the Network-Layer Protocol phase can have begun—yet a name used by an application may still have nowhere to stand on the far network. RFC 2097 made that missing step visible.

Published in January 1997, the PPP NetBIOS Frames Control Protocol assigned 0x803f to NBFCP control packets and 0x003f to NBF datagrams. Its declared topology was narrow. An end system could connect to a peer or to the LAN attached to that peer. The protocol was not for joining two LANs; NetBIOS name limits and name-defense behavior made that larger claim unsafe.

That constraint matters because NBF was not a routable network layer in the IP sense. The peer might act as a gateway, a bridge, a local-access-only server or another end system. Reaching that peer did not settle which names it could expose, what broadcasts or multicasts it would pass, or which frame information it needed. NBFCP turned those questions into negotiated records.

Opening the carrier and admitting the names were different events

PPP divided work into phases. LCP established, configured and tested the data link. Authentication and link-quality procedures could intervene. Only in the Network-Layer Protocol phase could NBFCP exchange its packets; an implementation receiving them earlier was supposed to discard them silently. NBF datagrams could flow only after NBFCP reached Opened.

Even that Opened state was not a universal green light. For end systems, RFC 2097 required negotiation of Name-Projection. The sender listed the sixteen-octet NetBIOS names it wanted the remote peer to add to the remote network. A name entry also carried whether it was unique or a group name. Because the option's one-octet Length field could describe at most fourteen names, a peer with more identities had to send several Name-Projection options.

This was not a bulk declaration that the endpoint “had NetBIOS.” It was an application-shaped request surface. A workstation could present several names for different services or roles. The far peer had to try to give each name a usable presence on its side.

Partial acceptance had to remain visible

If the receiving peer could not add every requested name, it had to return a Configure-Nak containing the complete list. A successfully added name carried Added=0; a failed name carried a non-zero result. The RFC listed distinct outcomes: a duplicate in the local table, a full table, a name already in use on the remote NetBIOS, a detected conflict, a name defined by another environment, or exhausted system resources.

The list was therefore both proposal and receipt. Two names in one request could acquire different operational fates. The sender should then resubmit the names that succeeded, but it retained a choice: continue with the admitted subset or terminate NBFCP because the full bundle was necessary. A partial success did not let the network decide what the missing name meant to the application.

Time also belonged to the evidence. Adding NetBIOS names commonly took about three seconds, the same duration PPP might use as a default restart timer. RFC 2097 recommended ten seconds during name configuration. A fast retry could be an artifact of an impatient control loop rather than proof that the remote system was absent.

Added=0 consequently supports a precise statement: in that exchange, this peer reported that it could add this requested name. It does not prove that every other segment, name server or bridge held a consistent view. RFC 1001 itself warned that failures could leave inconsistent name information. Local name defense is valuable precisely because its scope is bounded.

The peer described its role without proving its identity

Peer-Information let a side report an implementation class, a major and minor version, and an optional peer name. The initial classes distinguished a PPP NetBIOS gateway server, a local-access-only server, an NBF bridge and an end system, with other values reserved for legacy implementations.

This metadata was operationally useful. A remote machine connected to a bridge faced a different forwarding surface from one connected to a server that would not pass packets onward. Yet the option was suggested rather than mandatory, and the peer supplied its own class and name. RFC 2097 provided no authentication binding between those octets and a verified organization, machine or operator. The class could guide handling; it could not serve as an identity certificate.

Multicast policy could make a reachable service invisible

NetBIOS applications differed in their dependence on multicast. Some needed multicast traffic to function; others needed none of it. NBFCP's Multicast-Filtering option therefore exposed a maximum forwarding period and a priority bit.

A period of zero asked for all multicast packets to be forwarded. A normal value, capped at sixty seconds, described a rate no more frequent than once in that interval. 0xFFFF handled an unknown or unavailable value depending on whether it appeared in a Request or Nak. Priority selected whether multicast or directed packets should go first.

These controls converted bandwidth policy into application behavior. A link could be open, names could be projected, and directed packets could move while an application that relied on frequent multicasts appeared broken. Agreement on a period did not prove that every multicast would arrive. It specified the remote handling policy; queueing, loss, later filtering and application consumption remained separate facts.

Twelve extra octets changed the admissible envelope

NBF packets appeared with several historical MAC-header forms—802.3 Ethernet, 802.5 Token Ring, DIX Ethernet and FDDI. Some PPP implementations needed full media headers to bridge the traffic; smarter ones needed only IEEE addresses; gateways might need none.

The IEEE-MAC-Address-Required option expressed that dependency. By default, the NBF payload carried no MAC header. If the option succeeded, every NBF datagram had to begin with a twelve-octet destination/source IEEE MAC header. Because this decision came after LCP had negotiated the PPP maximum receive unit, implementations accepting the option also had to receive NBF packets twelve octets larger than that MRU.

That exception is a compact reminder that a lower-layer number was not the whole packet contract. The later NCP could introduce a required envelope around its own protocol. Observing the header proved which representation was used, not that a bridge forwarded it or that the named destination received it.

Opened was a permission boundary, not a result certificate

RFC 2097's four options separated facts that operational summaries tend to collapse. Which names were admitted? What kind of peer claimed to be present? What multicast treatment was promised? Which MAC envelope was required? Only after those answers could Opened authorize NBF datagrams on this point-to-point link.

The protocol was equally clear about what lay outside the receipt. Its Security Considerations section did not discuss security. NBFCP did not authenticate a person or machine, authorize a name, encrypt data, prove integrity or establish rights to a LAN resource. Its topology statement rejected LAN-to-LAN use rather than pretending that local name projection created a routed network.

The current IANA registry still lists the control and data protocol values, the four options, the name-result codes and peer classes. That persistence proves stable identifiers. It does not prove present deployment, product conformance or successful interoperability. The RFC Editor lists no current errata, which is a statement about the errata register, not about every implementation.

The contrast with RFC 1088 is especially useful. RFC 1088 mechanically derived a NetBIOS name from an IPv4 address for IP-over-NetBIOS delivery. RFC 2097 did not derive the name; it carried a peer's chosen name set to a remote admission point and returned per-name outcomes. One mechanism named a datagram destination. The other negotiated whether named presences could be projected across a remote-access boundary.

Read through Lu Heng's later Minimum Initial Specification and Running-Code Primacy framework, NBFCP is a small example of a shared layer that states only the commitments the endpoints need to interoperate, while leaving application choice local. That is an editorial reading, not evidence of the RFC author's intention. The historical fact is enough: link-up stopped being shorthand for access once the names, peer role, multicast policy and frame form each acquired their own receipt.

Sources