Network Working Group Request for Comments: 1001 March, 1987 PROTOCOL STANDARD FOR A NetBIOS SERVICE ON A TCP/UDP TRANSPORT: CONCEPTS AND METHODS ABSTRACT This RFC defines a proposed standard protocol to support NetBIOS services in a TCP/IP environment. Both local network and internet operation are supported. Various node types are defined to accommodate local and internet topologies and to allow operation with or without the use of IP broadcast. This RFC describes the NetBIOS-over-TCP protocols in a general manner, emphasizing the underlying ideas and techniques. Detailed specifications are found in a companion RFC, "Protocol Standard For a NetBIOS Service on a TCP/UDP Transport: Detailed Specifications".
SUMMARY OF CONTENTS 1. STATUS OF THIS MEMO 6 2. ACKNOWLEDGEMENTS 6 3. INTRODUCTION 7 4. DESIGN PRINCIPLES 7 5. OVERVIEW OF NetBIOS 10 6. NetBIOS FACILITIES SUPPORTED BY THIS STANDARD 15 7. REQUIRED SUPPORTING SERVICE INTERFACES AND DEFINITIONS 15 8. RELATED PROTOCOLS AND SERVICES 16 9. NetBIOS SCOPE 16 10. NetBIOS END-NODES 16 11. NetBIOS SUPPORT SERVERS 18 12. TOPOLOGIES 20 13. GENERAL METHODS 23 14. REPRESENTATION OF NETBIOS NAMES 25 15. NetBIOS NAME SERVICE 27 16. NetBIOS SESSION SERVICE 48 17. NETBIOS DATAGRAM SERVICE 55 18. NODE CONFIGURATION PARAMETERS 58 19. MINIMAL CONFORMANCE 59 REFERENCES 60 APPENDIX A - INTEGRATION WITH INTERNET GROUP MULTICASTING 61 APPENDIX B - IMPLEMENTATION CONSIDERATIONS 62
TABLE OF CONTENTS 1. STATUS OF THIS MEMO 6 2. ACKNOWLEDGEMENTS 6 3. INTRODUCTION 7 4. DESIGN PRINCIPLES 8 4.1 PRESERVE NetBIOS SERVICES 8 4.2 USE EXISTING STANDARDS 8 4.3 MINIMIZE OPTIONS 8 4.4 TOLERATE ERRORS AND DISRUPTIONS 8 4.5 DO NOT REQUIRE CENTRAL MANAGEMENT 9 4.6 ALLOW INTERNET OPERATION 9 4.7 MINIMIZE BROADCAST ACTIVITY 9 4.8 PERMIT IMPLEMENTATION ON EXISTING SYSTEMS 9 4.9 REQUIRE ONLY THE MINIMUM NECESSARY TO OPERATE 9 4.10 MAXIMIZE EFFICIENCY 10 4.11 MINIMIZE NEW INVENTIONS 10 5. OVERVIEW OF NetBIOS 10 5.1 INTERFACE TO APPLICATION PROGRAMS 10 5.2 NAME SERVICE 11 5.3 SESSION SERVICE 12 5.4 DATAGRAM SERVICE 13 5.5 MISCELLANEOUS FUNCTIONS 14 5.6 NON-STANDARD EXTENSIONS 15 6. NetBIOS FACILITIES SUPPORTED BY THIS STANDARD 15 7. REQUIRED SUPPORTING SERVICE INTERFACES AND DEFINITIONS 15 8. RELATED PROTOCOLS AND SERVICES 16 9. NetBIOS SCOPE 16 10. NetBIOS END-NODES 16 10.1 BROADCAST (B) NODES 16 10.2 POINT-TO-POINT (P) NODES 16 10.3 MIXED MODE (M) NODES 16 11. NetBIOS SUPPORT SERVERS 18 11.1 NetBIOS NAME SERVER (NBNS) NODES 18 11.1.1 RELATIONSHIP OF THE NBNS TO THE DOMAIN NAME SYSTEM 19 11.2 NetBIOS DATAGRAM DISTRIBUTION SERVER (NBDD) NODES 19 11.3 RELATIONSHIP OF NBNS AND NBDD NODES 20 11.4 RELATIONSHIP OF NetBIOS SUPPORT SERVERS AND B NODES 20 12. TOPOLOGIES 20 12.1 LOCAL 20
12.1.1 B NODES ONLY 21 12.1.2 P NODES ONLY 21 12.1.3 MIXED B AND P NODES 21 12.2 INTERNET 22 12.2.1 P NODES ONLY 22 12.2.2 MIXED M AND P NODES 23 13. GENERAL METHODS 23 13.1 REQUEST/RESPONSE INTERACTION STYLE 23 13.1.1 RETRANSMISSION OF REQUESTS 24 13.1.2 REQUESTS WITHOUT RESPONSES: DEMANDS 24 13.2 TRANSACTIONS 25 13.2.1 TRANSACTION ID 25 13.3 TCP AND UDP FOUNDATIONS 25 14. REPRESENTATION OF NETBIOS NAMES 25 14.1 FIRST LEVEL ENCODING 26 14.2 SECOND LEVEL ENCODING 27 15. NetBIOS NAME SERVICE 27 15.1 OVERVIEW OF NetBIOS NAME SERVICE 27 15.1.1 NAME REGISTRATION (CLAIM) 27 15.1.2 NAME QUERY (DISCOVERY) 28 15.1.3 NAME RELEASE 28 184.108.40.206 EXPLICIT RELEASE 28 220.127.116.11 NAME LIFETIME AND REFRESH 29 18.104.22.168 NAME CHALLENGE 29 22.214.171.124 GROUP NAME FADE-OUT 29 126.96.36.199 NAME CONFLICT 30 15.1.4 ADAPTER STATUS 31 15.1.5 END-NODE NBNS INTERACTION 31 188.8.131.52 UDP, TCP, AND TRUNCATION 31 184.108.40.206 NBNS WACK 32 220.127.116.11 NBNS REDIRECTION 32 15.1.6 SECURED VERSUS NON-SECURED NBNS 32 15.1.7 CONSISTENCY OF THE NBNS DATA BASE 32 15.1.8 NAME CACHING 34 15.2 NAME REGISTRATION TRANSACTIONS 34 15.2.1 NAME REGISTRATION BY B NODES 34 15.2.2 NAME REGISTRATION BY P NODES 35 18.104.22.168 NEW NAME, OR NEW GROUP MEMBER 35 22.214.171.124 EXISTING NAME AND OWNER IS STILL ACTIVE 36 126.96.36.199 EXISTING NAME AND OWNER IS INACTIVE 37 15.2.3 NAME REGISTRATION BY M NODES 38 15.3 NAME QUERY TRANSACTIONS 39 15.3.1 QUERY BY B NODES 39 15.3.2 QUERY BY P NODES 40 15.3.3 QUERY BY M NODES 43 15.3.4 ACQUIRE GROUP MEMBERSHIP LIST 43 15.4 NAME RELEASE TRANSACTIONS 44 15.4.1 RELEASE BY B NODES 44
15.4.2 RELEASE BY P NODES 44 15.4.3 RELEASE BY M NODES 44 15.5 NAME MAINTENANCE TRANSACTIONS 45 15.5.1 NAME REFRESH 45 15.5.2 NAME CHALLENGE 46 15.5.3 CLEAR NAME CONFLICT 47 15.6 ADAPTER STATUS TRANSACTIONS 47 16. NetBIOS SESSION SERVICE 48 16.1 OVERVIEW OF NetBIOS SESSION SERVICE 49 16.1.1 SESSION ESTABLISHMENT PHASE OVERVIEW 49 188.8.131.52 RETRYING AFTER BEING RETARGETTED 50 184.108.40.206 SESSION ESTABLISHMENT TO A GROUP NAME 51 16.1.2 STEADY STATE PHASE OVERVIEW 51 16.1.3 SESSION TERMINATION PHASE OVERVIEW 51 16.2 SESSION ESTABLISHMENT PHASE 52 16.3 SESSION DATA TRANSFER PHASE 54 16.3.1 DATA ENCAPSULATION 54 16.3.2 SESSION KEEP-ALIVES 54 17. NETBIOS DATAGRAM SERVICE 55 17.1 OVERVIEW OF NetBIOS DATAGRAM SERVICE 55 17.1.1 UNICAST, MULTICAST, AND BROADCAST 55 17.1.2 FRAGMENTATION OF NetBIOS DATAGRAMS 55 17.2 NetBIOS DATAGRAMS BY B NODES 57 17.3 NetBIOS DATAGRAMS BY P AND M NODES 58 18. NODE CONFIGURATION PARAMETERS 58 19. MINIMAL CONFORMANCE 59 REFERENCES 60 APPENDIX A 61 INTEGRATION WITH INTERNET GROUP MULTICASTING 61 A-1. ADDITIONAL PROTOCOL REQUIRED IN B AND M NODES 61 A-2. CONSTRAINTS 61 APPENDIX B 62 IMPLEMENTATION CONSIDERATIONS 62 B-1. IMPLEMENTATION MODELS 62 B-1.1 MODEL INDEPENDENT CONSIDERATIONS 63 B-1.2 SERVICE OPERATION FOR EACH MODEL 63 B-2. CASUAL AND RESTRICTED NetBIOS APPLICATIONS 64 B-3. TCP VERSUS SESSION KEEP-ALIVES 66 B-4. RETARGET ALGORITHMS 67 B-5. NBDD SERVICE 68 B-6. APPLICATION CONSIDERATIONS 68 B-6.1 USE OF NetBIOS DATAGRAMS 68
PROTOCOL STANDARD FOR A NetBIOS SERVICE ON A TCP/UDP TRANSPORT: CONCEPTS AND METHODS 1. STATUS OF THIS MEMO This RFC specifies a proposed standard for the Internet community. Since this topic is new to the Internet community, discussions and suggestions are specifically requested. Please send written comments to: Karl Auerbach Epilogue Technology Corporation P.O. Box 5432 Redwood City, CA 94063 Please send online comments to: Avnish Aggarwal Internet: email@example.com Usenet: ucbvax!mtxinu!excelan!avnish Distribution of this document is unlimited. 2. ACKNOWLEDGEMENTS This RFC has been developed under the auspices of the Internet Activities Board, especially the End-to-End Services Task Force. The following individuals have contributed to the development of this RFC: Avnish Aggarwal Arvind Agrawal Lorenzo Aguilar Geoffrey Arnold Karl Auerbach K. Ramesh Babu Keith Ball Amatzia Ben-Artzi Vint Cerf Richard Cherry David Crocker Steve Deering Greg Ennis Steve Holmgren Jay Israel David Kaufman Lee LaBarre James Lau Dan Lynch Gaylord Miyata David Stevens Steve Thomas Ishan Wu The system proposed by this RFC does not reflect any existing Netbios-over-TCP implementation. However, the design incorporates considerable knowledge obtained from prior implementations. Special thanks goes to the following organizations which have provided this invaluable information: CMC/Syros Excelan Sytek Ungermann-Bass
3. INTRODUCTION This RFC describes the ideas and general methods used to provide NetBIOS on a TCP and UDP foundation. A companion RFC, "Protocol Standard For a NetBIOS Service on a TCP/UDP Transport: Detailed Specifications" contains detailed descriptions of packet formats, protocols, and defined constants and variables. The NetBIOS service has become the dominant mechanism for personal computer networking. NetBIOS provides a vendor independent interface for the IBM Personal Computer (PC) and compatible systems. NetBIOS defines a software interface not a protocol. There is no "official" NetBIOS service standard. In practice, however, the IBM PC-Network version is used as a reference. That version is described in the IBM document 6322916, "Technical Reference PC Network". Protocols supporting NetBIOS services have been constructed on diverse protocol and hardware foundations. Even when the same foundation is used, different implementations may not be able to interoperate unless they use a common protocol. To allow NetBIOS interoperation in the Internet, this RFC defines a standard protocol to support NetBIOS services using TCP and UDP. NetBIOS has generally been confined to personal computers to date. However, since larger computers are often well suited to run certain NetBIOS applications, such as file servers, this specification has been designed to allow an implementation to be built on virtually any type of system where the TCP/IP protocol suite is available. This standard defines a set of protocols to support NetBIOS services. These protocols are more than a simple communications service involving two entities. Rather, this note describes a distributed system in which many entities play a part even if they are not involved as an end-point of a particular NetBIOS connection. This standard neither constrains nor determines how those services are presented to application programs. Nevertheless, it is expected that on computers operating under the PC-DOS and MS-DOS operating systems that the existing NetBIOS interface will be preserved by implementors. NOTE: Various symbolic values are used in this document. For their definitions, refer to the Detailed Specifications.
4. DESIGN PRINCIPLES In order to develop the specification the following design principles were adopted to guide the effort. Most are typical to any protocol standardization effort; however, some have been assigned priorities that may be considered unusual. 4.1. PRESERVE NetBIOS SERVICES In the absence of an "official" standard for NetBIOS services, the version found in the IBM PC Network Technical Reference is used. NetBIOS is the foundation of a large body of existing applications. It is desirable to operate these applications on TCP networks and to extend them beyond personal computers into larger hosts. To support these applications, NetBIOS on TCP must closely conform to the services offered by existing NetBIOS systems. IBM PC-Network NetBIOS contains some implementation specific characteristics. This standard does not attempt to completely preserve these. It is certain that some existing software requires these characteristics and will fail to operate correctly on a NetBIOS service based on this RFC. 4.2. USE EXISTING STANDARDS Protocol development, especially with standardization, is a demanding process. The development of new protocols must be minimized. It is considered essential that an existing standard which provides the necessary functionality with reasonable performance always be chosen in preference to developing a new protocol. When a standard protocol is used, it must be unmodified. 4.3. MINIMIZE OPTIONS The standard for NetBIOS on TCP should contain few, if any, options. Where options are included, the options should be designed so that devices with different option selections should interoperate. 4.4. TOLERATE ERRORS AND DISRUPTIONS NetBIOS networks typically operate in an uncontrolled environment. Computers come on-line at arbitrary times. Computers usually go off-line without any notice to their peers. The software is often operated by users who are unfamiliar with networks and who may randomly perturb configuration settings. Despite this chaos, NetBIOS networks work. NetBIOS on TCP must also
be able to operate well in this environment. Robust operation does not necessarily mean that the network is proof against all disruptions. A typical NetBIOS network may be disrupted by certain types of behavior, whether inadvertent or malicious. 4.5. DO NOT REQUIRE CENTRAL MANAGEMENT NetBIOS on TCP should be able to operate, if desired, without centralized management beyond that typically required by a TCP based network. 4.6. ALLOW INTERNET OPERATION The proposed standard recognizes the need for NetBIOS operation across a set of networks interconnected by network (IP) level relays (gateways.) However, the standard assumes that this form of operation will be less frequent than on the local MAC bridged-LAN. 4.7. MINIMIZE BROADCAST ACTIVITY The standard pre-supposes that the only broadcast services are those supported by UDP. Multicast capabilities are not assumed to be available in any form. Despite the availability of broadcast capabilities, the standard recognizes that some administrations may wish to avoid heavy broadcast activity. For example, an administration may wish to avoid isolated non-participating hosts from the burden of receiving and discarding NetBIOS broadcasts. 4.8. PERMIT IMPLEMENTATION ON EXISTING SYSTEMS The NetBIOS on TCP protocol should be implementable on common operating systems, such as Unix(tm) and VAX/VMS(tm), without massive effort. The NetBIOS protocols should not require services typically unavailable on presently existing TCP/UDP/IP implementations. 4.9. REQUIRE ONLY THE MINIMUM NECESSARY TO OPERATE The protocol definition should specify only the minimal set of protocols required for interoperation. However, additional protocol elements may be defined to enhance efficiency. These latter elements may be generated at the option of the sender, although they must be accepted by all receivers.
4.10. MAXIMIZE EFFICIENCY To be useful, a protocol must conduct its business quickly. 4.11. MINIMIZE NEW INVENTIONS When an existing protocol is not quite able to support a necessary function, but with a small amount of change, it could, that protocol should be used. This is felt to be easier to achieve than development of new protocols; further, it is likely to have more general utility for the Internet. 5. OVERVIEW OF NetBIOS This section describes the NetBIOS services. It is for background information only. The reader may chose to skip to the next section. NetBIOS was designed for use by groups of PCs, sharing a broadcast medium. Both connection (Session) and connectionless (Datagram) services are provided, and broadcast and multicast are supported. Participants are identified by name. Assignment of names is distributed and highly dynamic. NetBIOS applications employ NetBIOS mechanisms to locate resources, establish connections, send and receive data with an application peer, and terminate connections. For purposes of discussion, these mechanisms will collectively be called the NetBIOS Service. This service can be implemented in many different ways. One of the first implementations was for personal computers running the PC-DOS and MS-DOS operating systems. It is possible to implement NetBIOS within other operating systems, or as processes which are, themselves, simply application programs as far as the host operating system is concerned. The NetBIOS specification, published by IBM as "Technical Reference PC Network" defines the interface and services available to the NetBIOS user. The protocols outlined by that document pertain only to the IBM PC Network and are not generally applicable to other networks. 5.1. INTERFACE TO APPLICATION PROGRAMS NetBIOS on personal computers includes both a set of services and an exact program interface to those services. NetBIOS on other computer systems may present the NetBIOS services to programs using other interfaces. Except on personal computers, no clear standard for a NetBIOS software interface has emerged.
5.2. NAME SERVICE NetBIOS resources are referenced by name. Lower-level address information is not available to NetBIOS applications. An application, representing a resource, registers one or more names that it wishes to use. The name space is flat and uses sixteen alphanumeric characters. Names may not start with an asterisk (*). Registration is a bid for use of a name. The bid may be for exclusive (unique) or shared (group) ownership. Each application contends with the other applications in real time. Implicit permission is granted to a station when it receives no objections. That is, a bid is made and the application waits for a period of time. If no objections are received, the station assumes that it has permission. A unique name should be held by only one station at a time. However, duplicates ("name conflicts") may arise due to errors. All instances of a group name are equivalent. An application referencing a name generally does not know (or care) whether the name is registered as a unique or a group name. An explicit name deletion function is specified, so that applications may remove a name. Implicit name deletion occurs when a station ceases operation. In the case of personal computers, implicit name deletion is a frequent occurrence. The Name Service primitives are: 1) Add Name The requesting application wants exclusive use of the name. 2) Add Group Name The requesting application is willing to share use of the name with other applications. 3) Delete Name The application no longer requires use of the name. It is important to note that typical use of NetBIOS is among independently-operated personal computers. A common way to stop using a PC is to turn it off; in this case, the graceful give-back mechanism, provided by the Delete Name function, is not used. Because this occurs frequently, the network service must support this behavior.
5.3. SESSION SERVICE A session is a reliable message exchange, conducted between a pair of NetBIOS applications. Sessions are full-duplex, sequenced, and reliable. Data is organized into messages. Each message may range in size from 0 to 131,071 bytes. No expedited or urgent data capabilities are present. Multiple sessions may exist between any pair of calling and called names. The parties to a connection have access to the calling and called names. The NetBIOS specification does not define how a connection request to a shared (group) name resolves into a session. The usual assumption is that a session may be established with any one owner of the called group name. An important service provided to NetBIOS applications is the detection of sessions failure. The loss of a session is reported to an application via all of the outstanding service requests for that session. For example, if the application has only a NetBIOS receive primitive pending and the session terminates, the pending receive will abort with a termination indication. Session Service primitives are: 1) Call Initiate a session with a process that is listening under the specified name. The calling entity must indicate both a calling name (properly registered to the caller) and a called name. 2) Listen Accept a session from a caller. The listen primitive may be constrained to accept an incoming call from a named caller. Alternatively, a call may be accepted from any caller. 3) Hang Up Gracefully terminate a session. All pending data is transferred before the session is terminated. 4) Send Transmit one message. A time-out can occur. A time-out of any session send forces the non-graceful termination of the session.
A "chain send" primitive is required by the PC NetBIOS software interface to allow a single message to be gathered from pieces in various buffers. Chain Send is an interface detail and does not effect the protocol. 5) Receive Receive data. A time-out can occur. A time-out on a session receive only terminates the receive, not the session, although the data is lost. The receive primitive may be implemented with variants, such as "Receive Any", which is required by the PC NetBIOS software interface. Receive Any is an interface detail and does not effect the protocol. 6) Session Status Obtain information about all of the requestor's sessions, under the specified name. No network activity is involved. 5.4. DATAGRAM SERVICE The Datagram service is an unreliable, non-sequenced, connectionless service. Datagrams are sent under cover of a name properly registered to the sender. Datagrams may be sent to a specific name or may be explicitly broadcast. Datagrams sent to an exclusive name are received, if at all, by the holder of that name. Datagrams sent to a group name are multicast to all holders of that name. The sending application program cannot distinguish between group and unique names and thus must act as if all non-broadcast datagrams are multicast. As with the Session Service, the receiver of the datagram is told the sending and receiving names. Datagram Service primitives are: 1) Send Datagram Send an unreliable datagram to an application that is associated with the specified name. The name may be unique or group; the sender is not aware of the difference. If the name belongs to a group, then each member is to receive the datagram.
2) Send Broadcast Datagram Send an unreliable datagram to any application with a Receive Broadcast Datagram posted. 3) Receive Datagram Receive a datagram sent by a specified originating name to the specified name. If the originating name is an asterisk, then the datagram may have been originated under any name. Note: An arriving datagram will be delivered to all pending Receiving Datagrams that have source and destination specifications matching those of the datagram. In other words, if a program (or group of programs) issue a series of identical Receive Datagrams, one datagram will cause the entire series to complete. 4) Receive Broadcast Datagram Receive a datagram sent as a broadcast. If there are multiple pending Receive Broadcast Datagram operations pending, all will be satisfied by the same received datagram. 5.5. MISCELLANEOUS FUNCTIONS The following functions are present to control the operation of the hardware interface to the network. These functions are generally implementation dependent. 1) Reset Initialize the local network adapter. 2) Cancel Abort a pending NetBIOS request. The successful cancel of a Send (or Chain Send) operation will terminate the associated session. 3) Adapter Status Obtain information about the local network adapter or of a remote adapter. 4) Unlink For use with Remote Program Load (RPL). Unlink redirects the PC boot disk device back to the local disk. See the
NetBIOS specification for further details concerning RPL and the Unlink operation (see page 2-35 in ). 5) Remote Program Load Remote Program Load (RPL) is not a NetBIOS function. It is a NetBIOS application defined by IBM in their NetBIOS specification (see pages 2-80 through 2-82 in ). 5.6. NON-STANDARD EXTENSIONS The IBM Token Ring implementation of NetBIOS has added at least one new user capability: 1) Find Name This function determines whether a given name has been registered on the network. 6. NetBIOS FACILITIES SUPPORTED BY THIS STANDARD The protocol specified by this standard permits an implementer to provide all of the NetBIOS services as described in the IBM "Technical Reference PC Network". The following NetBIOS facilities are outside the scope of this specification. These are local implementation matters and do not impact interoperability: - RESET - SESSION STATUS - UNLINK - RPL (Remote Program Load) 7. REQUIRED SUPPORTING SERVICE INTERFACES AND DEFINITIONS The protocols described in this RFC require service interfaces to the following: - TCP[3,4] - UDP Byte ordering, addressing conventions (including addresses to be used for broadcasts and multicasts) are defined by the most recent version of: - Assigned Numbers Additional definitions and constraints are in:
- IP - Internet Subnets[8,9,10] 8. RELATED PROTOCOLS AND SERVICES The design of the protocols described in this RFC allow for the future incorporation of the following protocols and services. However, before this may occur, certain extensions may be required to the protocols defined in this RFC or to those listed below. - Domain Name Service[11,12,13,14] - Internet Group Multicast[15,16] 9. NetBIOS SCOPE A "NetBIOS Scope" is the population of computers across which a registered NetBIOS name is known. NetBIOS broadcast and multicast datagram operations must reach the entire extent of the NetBIOS scope. An internet may support multiple, non-intersecting NetBIOS Scopes. Each NetBIOS scope has a "scope identifier". This identifier is a character string meeting the requirements of the domain name system for domain names. NOTE: Each implementation of NetBIOS-over-TCP must provide mechanisms to manage the scope identifier(s) to be used. Control of scope identifiers implies a requirement for additional NetBIOS interface capabilities. These may be provided through extensions of the user service interface or other means (such as node configuration parameters.) The nature of these extensions is not part of this specification.