Internet Draft F. Noon UB March 1992 HYBRID NETBIOS END-NODES STATUS OF THIS MEMO Implementations of NetBIOS-over-TCP may choose to adopt the procedures discussed, but not doing so will not meaningfully affect interoperability. Distribution of this memo is unlimited. 1. CHARACTERISTICS OF B, P, AND M NODES STD-19/RFC-1001/RFC-1002 defines a "Protocol Standard for a NetBIOS Service on a TCP/UDP Transport," or "NetBIOS-over-TCP" for short. STD-19 defines NetBIOS end-nodes as stations which "support NetBIOS service interfaces and contain applications." It describes three types of end-node: - Broadcast nodes (B nodes) - Point-to-point nodes (P nodes) - Mixed mode nodes (M nodes) The B node relies upon IP broadcasts to effect parts of the NetBIOS Name and Datagram Services (and so, indirectly, the Session Service as well). For example, to discover the owner of a NetBIOS name it must broadcast a Name Query Request packet over UDP. The chief limitation of the B node is that it is limited to the range of its broadcast area, not being able to arbitrarily cross IP routers. Also, many sites only reluctantly allow a protocol on their network which regularly engages in broadcast traffic. The P node has no such limitations, as it never broadcasts UDP datagrams; instead it contacts special NetBIOS servers directly. It utterly relies upon these stations, which implement a NetBIOS Name Service (NBNS) server and a NetBIOS Datagram Distribution (NBDD) server. If either server becomes unavailable NetBIOS services are crippled or stop. For example, if the NBNS server fails or is unreachable, a booting P node cannot register its own name; for a microcomputer this often means that it must abort loading its network operating system until it can be restarted. The M node is basically a P node which can transmit UDP broadcasts to locate owners of NetBIOS names. This is allowed under the assumption that end-nodes will be searching for "local" resources most of the time, so broadcasts could prove efficient. Otherwise the M node Noon [Page 1] Internet Draft Hybrid NetBIOS End-Nodes March 1992 remains as dependent upon NBNS and NBDD servers as is the P node. For example, an M node cannot register a NetBIOS name unless it can contact its NBNS server; until it registers its name it cannot engage in other NetBIOS transactions. This severely limits the robustness of such systems. 2. MOTIVATION FOR A FOURTH END-NODE TYPE Previous specification of NetBIOS-over-TCP creates a deployment dilemma for implementers of sizable TCP/IP networks which incorporate IP routers. B nodes are not really suited for such an environment, which leaves P and M nodes. But these are quite dependent upon NBNS and NBDD servers for their continued operation on the network. On the one hand one wishes to have many of these critical servers in the network; say between every pair of routers, bridges, or other links which may occasionally fail. On the other hand the costs of deploying that many servers, the small amount of work each one would probably be fielding at one segment each, and the additional headaches of maintaining the whole operation, is discouraging. The end-node specified by this RFC has a style of operation assuring greater robustness than P or M nodes, while remaining suitable for large internetworks and minimizing use of IP broadcasts. It uses the same NetBIOS servers as do P and M nodes, and is therefore fully interoperable with these other end-node types. 3. THE H NODE TRANSACTION STYLE This RFC specifies a fourth end-node type: a Hybrid (H) node. The H node is similar to an M node in that it maintains both B node characteristics (use of IP broadcasts) and P node characteristics (use of NBNS and NBDD servers). Unlike the M node, however, the emphasis is placed upon the robustness of the NetBIOS Services offered to applications on the end-node. If an NBNS or NBDD server becomes unavailable connectivity may be reduced (the network has been partitioned) but all NetBIOS services will continue to function properly. Unless otherwise specified below, the behavior of the H node is identical to that of the M node. The H node always listens for IP broadcasts on both the NetBIOS Name and Datagram Service UDP ports. This is to maintain connectivity with fellow H nodes which can, under conditions specified below, use UDP broadcasts for these services. For convenience I assume that the H node maintains two boolean variables: NBNS-AVAILABLE and NBDD-AVAILABLE. These are initially both TRUE, meaning that the H node will try to use its NBNS and NBDD servers whenever possible. NBNS-AVAILABLE is toggled to FALSE whenever an attempt to contact the NBNS server fails. With the flag Noon [Page 2] Internet Draft Hybrid NetBIOS End-Nodes March 1992 in this state the H node uses the B node transaction style, which doesn't use NBNS servers, for all protocol used for the NetBIOS Name Service. The H node periodically attempts to contact the NBNS server and, if ever successful, sets NBNS-AVAILABLE back to TRUE and begins using the NBNS server once more. (Attempting to contact the NBNS server on every transaction, involving retries then finally timing out, would cause much delay on a busy end-node.) Analogously, NBDD-AVAILABLE becomes FALSE whenever the NBDD server cannot be contacted, and returns to TRUE when polling reveals its return. While FALSE the H node uses the B node transaction style for passing Datagram Service protocol. The mechanism used to poll the servers is irrelevant. For polling an NBNS server a Name Query Request will work (use one of the station's unique names: otherwise the NBNS server may be wasting time gathering up a group name list). For polling an NBDD server a Datagram Query Request is most reliable. 3.1 Name Registration Like the M node, the H node registers names using a two-step procedure. First a Name Registration Request is broadcast so that any conflicts with H nodes having NBNS-AVAILABLE FALSE may be recognized. If this is successful the H node sends the request to an NBNS server. If the NBNS server accepts the name the H node owns it; if not, the name registration has failed. The key difference between the M node and the H node is exhibited when no NBNS server can be reached or NBNS-AVAILABLE is FALSE: the M node registration fails; the H node registration, provisionally, succeeds. At this point the H node continues on as best it can: NBNS-AVAILABLE is made FALSE (if it has been TRUE) and all NetBIOS Name Service protocol becomes that of the B node; no NBNS server is used. The H node periodically tries to contact the NBNS server, and if ever it succeeds sets NBNS-AVAILABLE TRUE and resumes use of the NBNS server for the Name Service. At this time all names claimed by the H node on the basis of broadcasts alone must be registered at the NBNS server. Any registration that fails results in the H node marking that name's entry "in conflict," and the usual name conflict rules apply. 3.2 Name Release H nodes release names just like M nodes. (There is an M node specification problem which I will attempt to unravel below.) A Name Release Request is sent to the NBNS server (if NBNS-AVAILABLE is TRUE). If the NBNS server responds with a Positive Name Release Response then the H node broadcasts a Name Release Demand and deletes the name from its local table. If the NBNS server responds with a Negative Name Release Response the H node does not issue the Demand; it retains ownership of the name unless the Noon [Page 3] Internet Draft Hybrid NetBIOS End-Nodes March 1992 result code in the response was ACT_ERR (active error). If an NBNS server cannot be reached, or NBNS-AVAILABLE is FALSE, the H node does not issue the Demand; it must retry the request when an NBNS server is again reachable. Because RFC 1001 does not model the NetBIOS interface itself it is unclear whether the NetBIOS service provider should retry the Name Release Request in the background, or whether the user of NetBIOS should retry the request. The first case can be awkward for the provider to implement, and does not conform to the usual procedure of returning an error code to the user whenever problems develop. The second case is difficult because there is no appropriate error code defined for this situation and it is probably not a condition which a NetBIOS user would anticipate. If one assumes that names registered on the NBNS server will be given a finite time-to-live value (this should be standard procedure), then an implementation which simply issues the Demand and deletes the name from its table is little worse than a station which goes down before it can orderly release all the names it owns. This procedure allows the implementation to return the expected completion code (success), keeping application complexity down, and also eliminates awkward backfilling by the service provider. 3.3 Name Query The M node tries to find the owners of a name first by broadcasting; only if this fails does it query the NBNS server. In contrast, the H node sends a Name Query Request to the NBNS server whenever NBNS-AVAILABLE is TRUE. Only if NBNS-AVAILABLE is FALSE, if the NBNS server does not respond (NBNS-AVAILABLE is made FALSE), or if the NBNS server replies with a Negative Name Query Response, does the H node broadcast the request. 3.4 Datagram Service The H node uses an NBDD server whenever NBDD-AVAILABLE is TRUE. Only if NBDD-AVAILABLE is FALSE, or the NBDD server becomes unavailable (NBDD-AVAILABLE is made FALSE) does it resort to broadcasting UDP packets containing NetBIOS multicast or broadcast datagrams. 3.5 Mixing End-Node Types Similar problems arise when mixing B and H nodes in an internet environment as when mixing B and M nodes. The rule here is: B and H nodes should not operate in the same IP broadcast area. However P, M, and H nodes may be freely mixed in any combination. 4. PACKET ENCODING RFC 1002 defines the packet formats for NetBIOS-over-TCP. Since H nodes operate so similarly to other end-node types, these can be used Noon [Page 4] Internet Draft Hybrid NetBIOS End-Nodes March 1992 as-is except for those places where the end-node type is itself encoded. Only encodings for B, P, and M nodes are defined; preferably one would designate a fourth value to denote H nodes. Unfortunately other end-node types are not foreseen by RFC 1002, so there aren't always enough bits allocated to hold this new value. This occurs in three places: the encoding of the ONT (owner node type) bits of the NB_FLAGS and NAME_FLAGS fields, and in the SNT (source end-node type) bits of the FLAGS field of the datagram header. In each case there are 2 bits allocated, which would be enough to represent 4 end-node types, except that the SNT bits also have a value defined which denotes "NBDD." Because of this space problem, and because of the limited use for the end-node type information in the first place, the encoding which denotes "M node" should be used to refer to H nodes as well. This is appropriate, for both M and H nodes operate using IP broadcast as well as NBNS and NBDD servers. Hence the essential characteristics of the two end-node types, from the perspective of the protocols, are the same. 5. SECURITY CONSIDERATIONS There are no new security considerations beyond those of STD-19/ RFC-1001/RFC-1002. As specified above, M and H nodes must be segregated from B nodes. 6. AUTHOR'S ADDRESS Fredrik Noon Ungermann-Bass, Inc. P.O. Box 58030 (3900 Freedom Circle) Santa Clara, CA 95052-8030 USA Phone: (408) 562-5632 Fax: (408) 970-7389 EMail: fcn@ubvax.ub.com Noon [Page 5]