HTTP/1.1 200 OK Date: Tue, 09 Apr 2002 10:32:15 GMT Server: Apache/1.3.20 (Unix) Last-Modified: Wed, 09 Dec 1992 04:39:00 GMT ETag: "3dde4d-3a66-2b257864" Accept-Ranges: bytes Content-Length: 14950 Connection: close Content-Type: text/plain Internet Draft F. Noon Ungermann-Bass October 1992 Expires: April 1993 HYBRID NETBIOS END-NODES STATUS OF THIS MEMO This document is an Internet Draft. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its Areas, and its Working Groups. Note that other groups may also distribute working documents as Internet Drafts. Internet Drafts are draft documents valid for a maximum of six months. Internet Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material or to cite them other than as a "working draft" or "work in progress." Please check the I-D abstract listing contained in each Internet Draft directory to learn the current status of this or any other Internet Draft. This memo specifies an additional end-node type for NetBIOS-over-TCP. Implementation of this capability is optional; the previously specified P and M nodes fully interoperate with it. 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 confined within 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 that regularly engages in broadcast traffic. Noon [Page 1] Internet Draft Hybrid NetBIOS End-Nodes October 1992 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 that can transmit UDP broadcasts to locate owners of NetBIOS names. The assumption is that end-nodes will be searching for "local" resources most of the time, so broadcasts could prove efficient. Otherwise the M node 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 that 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 memo 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 memo 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 decrease (the network has been partitioned) but all NetBIOS services will continue to function properly. Noon [Page 2] Internet Draft Hybrid NetBIOS End-Nodes October 1992 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 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 again. (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, the H node toggles NBDD-AVAILABLE FALSE whenever it cannot contact its NBDD server, and sets it back to TRUE when polling reveals the server's availability. 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. To poll 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). To poll an NBDD server a Datagram Query Request is most reliable. 3.1 Name Registration If NBNS-AVAILABLE is TRUE the H node attempts to register a name by issuing a Name Registration Request to an NBNS server using the P node procedure. If there is a response, then the registration succeeds or fails depending upon whether the response is positive or negative. If there is no response the H node sets NBNS-AVAILABLE to FALSE and continues with the following procedure. If NBNS-AVAILABLE is FALSE the H node broadcasts a Name Registration Request using the B node procedure. If there is no response, then the name registration, provisionally, succeeds and the H node adds the name to its local list; otherwise, if the H node receives a Negative Name Registration Response, then the registration fails. Whenever the H node's polling loop toggles NBNS-AVAILABLE from FALSE to TRUE, the H node must register all names claimed by use of broadcasts alone with an NBNS server. Any registration that Noon [Page 3] Internet Draft Hybrid NetBIOS End-Nodes October 1992 fails results in the H node marking that name's entry "in conflict," and the usual name conflict rules apply. Note that this is wholly different from the M node name registration procedure. The M node always broadcasts a registration first, then (if successful) tries an NBNS server. The H node, however, avoids IP broadcasting whenever it can. The H node must be prepared to defend its names as does the B node: regardless the state of NBNS_AVAILABLE, a Name Registration Request received (as an IP broadcast) for one of the H node's unique names elicits a Negative Name Registration Response from the H node. 3.2 Name Release H nodes release names similarly to 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 deletes the name from its local table. If the NBNS server is not available, or responds with a Negative Name Release Response, the H node has the option of either forcing the deletion by broadcasting a Name Release Demand and deleting the entry from its table, or of retrying the release later. The retry option, which is implied in the specification of the M node (RFC 1001, 15.4.3) is problematical, however. 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 no 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. As both name discovery and registration have mechanisms to correct bad information at the NBNS server, whatever state the server is in should work itself out eventually. Noon [Page 4] Internet Draft Hybrid NetBIOS End-Nodes October 1992 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. The H node only broadcasts the request 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 having an RCODE value different from NAM_ERR ("name not found"; other RCODE values may indicate some problem with the NBNS server itself). The above procedure doesn't really change if the NBNS server(s) reply with a Redirect Name Query Response: it is the final reply (or time-out) which determines the H node's action. 3.4 Datagram Service The H node uses an NBDD server to deliver multicast or broadcast NetBIOS datagrams 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 IP broadcasts. 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 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 Noon [Page 5] Internet Draft Hybrid NetBIOS End-Nodes October 1992 of the two end-node types, from the perspective of the protocols, are the same. 5. SECURITY CONSIDERATIONS There are no new security considerations introduced which go beyond those implied by 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, bldg. HQ1 P.O. Box 58030 (3900 Freedom Circle) Santa Clara, CA 95052-8030 USA Email: fcn@ubvax.ub.com Phone: (408) 562-5632 Fax: (408) 970-7389 Noon [Page 6]