Network Working Group
Request for Comments: 1001 March, 1987
PROTOCOL STANDARD FOR A NetBIOS SERVICE
ON A TCP/UDP TRANSPORT:
CONCEPTS AND METHODS
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
APPENDIX A - INTEGRATION WITH INTERNET GROUP MULTICASTING 61
APPENDIX B - IMPLEMENTATION CONSIDERATIONS 62
TABLE OF CONTENTS
1. STATUS OF THIS MEMO 62. ACKNOWLEDGEMENTS 63. INTRODUCTION 74. DESIGN PRINCIPLES 84.1 PRESERVE NetBIOS SERVICES 84.2 USE EXISTING STANDARDS 84.3 MINIMIZE OPTIONS 84.4 TOLERATE ERRORS AND DISRUPTIONS 84.5 DO NOT REQUIRE CENTRAL MANAGEMENT 94.6 ALLOW INTERNET OPERATION 94.7 MINIMIZE BROADCAST ACTIVITY 94.8 PERMIT IMPLEMENTATION ON EXISTING SYSTEMS 94.9 REQUIRE ONLY THE MINIMUM NECESSARY TO OPERATE 94.10 MAXIMIZE EFFICIENCY 104.11 MINIMIZE NEW INVENTIONS 105. OVERVIEW OF NetBIOS 105.1 INTERFACE TO APPLICATION PROGRAMS 105.2 NAME SERVICE 115.3 SESSION SERVICE 125.4 DATAGRAM SERVICE 135.5 MISCELLANEOUS FUNCTIONS 145.6 NON-STANDARD EXTENSIONS 156. NetBIOS FACILITIES SUPPORTED BY THIS STANDARD 157. REQUIRED SUPPORTING SERVICE INTERFACES AND DEFINITIONS 158. RELATED PROTOCOLS AND SERVICES 169. NetBIOS SCOPE 1610. NetBIOS END-NODES 1610.1 BROADCAST (B) NODES 1610.2 POINT-TO-POINT (P) NODES 1610.3 MIXED MODE (M) NODES 1611. NetBIOS SUPPORT SERVERS 1811.1 NetBIOS NAME SERVER (NBNS) NODES 1811.1.1 RELATIONSHIP OF THE NBNS TO THE DOMAIN NAME SYSTEM 1911.2 NetBIOS DATAGRAM DISTRIBUTION SERVER (NBDD) NODES 1911.3 RELATIONSHIP OF NBNS AND NBDD NODES 2011.4 RELATIONSHIP OF NetBIOS SUPPORT SERVERS AND B NODES 2012. TOPOLOGIES 2012.1 LOCAL 20
15.4.2 RELEASE BY P NODES 4415.4.3 RELEASE BY M NODES 4415.5 NAME MAINTENANCE TRANSACTIONS 4515.5.1 NAME REFRESH 4515.5.2 NAME CHALLENGE 4615.5.3 CLEAR NAME CONFLICT 4715.6 ADAPTER STATUS TRANSACTIONS 4716. NetBIOS SESSION SERVICE 4816.1 OVERVIEW OF NetBIOS SESSION SERVICE 4916.1.1 SESSION ESTABLISHMENT PHASE OVERVIEW 49188.8.131.52 RETRYING AFTER BEING RETARGETTED 5016.1.1.2 SESSION ESTABLISHMENT TO A GROUP NAME 5116.1.2 STEADY STATE PHASE OVERVIEW 5116.1.3 SESSION TERMINATION PHASE OVERVIEW 5116.2 SESSION ESTABLISHMENT PHASE 5216.3 SESSION DATA TRANSFER PHASE 5416.3.1 DATA ENCAPSULATION 5416.3.2 SESSION KEEP-ALIVES 5417. NETBIOS DATAGRAM SERVICE 5517.1 OVERVIEW OF NetBIOS DATAGRAM SERVICE 5517.1.1 UNICAST, MULTICAST, AND BROADCAST 5517.1.2 FRAGMENTATION OF NetBIOS DATAGRAMS 5517.2 NetBIOS DATAGRAMS BY B NODES 5717.3 NetBIOS DATAGRAMS BY P AND M NODES 5818. NODE CONFIGURATION PARAMETERS 5819. MINIMAL CONFORMANCE 59
REFERENCES 60APPENDIX A61
INTEGRATION WITH INTERNET GROUP MULTICASTING 61
A-1. ADDITIONAL PROTOCOL REQUIRED IN B AND M NODES 61
A-2. CONSTRAINTS 61APPENDIX B62
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:
Epilogue Technology Corporation
P.O. Box 5432
Redwood City, CA 94063
Please send online comments to:
Distribution of this document is unlimited.
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
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
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
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
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
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
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
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
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
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
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
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
The parties to a connection have access to the calling and called
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
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:
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
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.
Transmit one message. A time-out can occur. A time-out of
any session send forces the non-graceful termination of the
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.
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
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
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
5.5. MISCELLANEOUS FUNCTIONS
The following functions are present to control the operation of the
hardware interface to the network. These functions are generally
Initialize the local network adapter.
Abort a pending NetBIOS request. The successful cancel of a
Send (or Chain Send) operation will terminate the associated
3) Adapter Status
Obtain information about the local network adapter or of a
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
- SESSION STATUS
- RPL (Remote Program Load)
7. REQUIRED SUPPORTING SERVICE INTERFACES AND DEFINITIONS
The protocols described in this RFC require service interfaces to the
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:
- 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
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.