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".
NetBIOS Working Group [Page 1]
RFC 1001 March 1987
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
NetBIOS Working Group [Page 2]
RFC 1001 March 1987
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
NetBIOS Working Group [Page 3]
RFC 1001 March 1987
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
15.1.3.1 EXPLICIT RELEASE 28
15.1.3.2 NAME LIFETIME AND REFRESH 29
15.1.3.3 NAME CHALLENGE 29
15.1.3.4 GROUP NAME FADE-OUT 29
15.1.3.5 NAME CONFLICT 30
15.1.4 ADAPTER STATUS 31
15.1.5 END-NODE NBNS INTERACTION 31
15.1.5.1 UDP, TCP, AND TRUNCATION 31
15.1.5.2 NBNS WACK 32
15.1.5.3 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
15.2.2.1 NEW NAME, OR NEW GROUP MEMBER 35
15.2.2.2 EXISTING NAME AND OWNER IS STILL ACTIVE 36
15.2.2.3 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
NetBIOS Working Group [Page 4]
RFC 1001 March 1987
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
16.1.1.1 RETRYING AFTER BEING RETARGETTED 50
16.1.1.2 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
NetBIOS Working Group [Page 5]
RFC 1001 March 1987
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: mtxinu!excelan!avnish@ucbvax.berkeley.edu
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
NetBIOS Working Group [Page 6]
RFC 1001 March 1987
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"[1] 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"[2].
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[1].
NetBIOS Working Group [Page 7]
RFC 1001 March 1987
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[2] 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
NetBIOS Working Group [Page 8]
RFC 1001 March 1987
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.
NetBIOS Working Group [Page 9]
RFC 1001 March 1987
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"[2] 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.
NetBIOS Working Group [Page 10]
RFC 1001 March 1987
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.
NetBIOS Working Group [Page 11]
RFC 1001 March 1987
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.
NetBIOS Working Group [Page 12]
RFC 1001 March 1987
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.
NetBIOS Working Group [Page 13]
RFC 1001 March 1987
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 Working Group [Page 14]
RFC 1001 March 1987
NetBIOS specification for further details concerning RPL and
the Unlink operation (see page 2-35 in [2]).
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 [2]).
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"[2].
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[5]
Byte ordering, addressing conventions (including addresses to be
used for broadcasts and multicasts) are defined by the most
recent version of:
- Assigned Numbers[6]
Additional definitions and constraints are in:
NetBIOS Working Group [Page 15]
RFC 1001 March 1987
- IP[7]
- 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.
10. NetBIOS END-NODES
End-nodes support NetBIOS service interfaces and contain
applications.
Three types of end-nodes are part of this standard:
- Broadcast ("B") nodes
- Point-to-point ("P") nodes
- Mixed mode ("M") nodes
An IP address may be associated with only one instance of one of the
above types.
Without having preloaded name-to-address tables, NetBIOS participants
NetBIOS Working Group [Page 16]
RFC 1001 March 1987
are faced with the task of dynamically resolving references to one
another. This can be accomplished with broadcast or mediated point-
to-point communications.
B nodes use local network broadcasting to effect a rendezvous with
one or more recipients. P and M nodes use the NetBIOS Name Server
(NBNS) and the NetBIOS Datagram Distribution Server (NBDD) for this
same purpose.
End-nodes may be combined in various topologies. No matter how
combined, the operation of the B, P, and M nodes is not altered.
NOTE: It is recommended that the administration of a NetBIOS
scope avoid using both M and B nodes within the same scope.
A NetBIOS scope should contain only B nodes or only P and M
nodes.
10.1. BROADCAST (B) NODES
Broadcast (or "B") nodes communicate using a mix of UDP datagrams
(both broadcast and directed) and TCP connections. B nodes may
freely interoperate with one another within a broadcast area. A
broadcast area is a single MAC-bridged "B-LAN". (See Appendix A for
a discussion of using Internet Group Multicasting as a means to
extend a broadcast area beyond a single B-LAN.)
10.2. POINT-TO-POINT (P) NODES
Point-to-point (or "P") nodes communicate using only directed UDP
datagrams and TCP sessions. P nodes neither generate nor listen for
broadcast UDP packets. P nodes do, however, offer NetBIOS level
broadcast and multicast services using capabilities provided by the
NBNS and NBDD.
P nodes rely on NetBIOS name and datagram distribution servers.
These servers may be local or remote; P nodes operate the same in
either case.
10.3. MIXED MODE (M) NODES
Mixed mode nodes (or "M") nodes are P nodes which have been given
certain B node characteristics. M nodes use both broadcast and
unicast. Broadcast is used to improve response time using the
assumption that most resources reside on the local broadcast medium
rather than somewhere in an internet.
M nodes rely upon NBNS and NBDD servers. However, M nodes may
continue limited operation should these servers be temporarily
unavailable.
NetBIOS Working Group [Page 17]
RFC 1001 March 1987
11. NetBIOS SUPPORT SERVERS
Two types of support servers are part of this standard:
- NetBIOS name server ("NBNS") nodes
- Netbios datagram distribution ("NBDD") nodes
NBNS and NBDD nodes are invisible to NetBIOS applications and are
part of the underlying NetBIOS mechanism.
NetBIOS name and datagram distribution servers are the focus of name
and datagram activity for P and M nodes.
Both the name (NBNS) and datagram distribution (NBDD) servers are
permitted to shift part of their operation to the P or M end-node
which is requesting a service.
Since the assignment of responsibility is dynamic, and since P and M
nodes must be prepared to operate should the NetBIOS server delegate
control to the maximum extent, the system naturally accommodates
improvements in NetBIOS server function. For example, as Internet
Group Multicasting becomes more widespread, new NBDD implementations
may elect to assume full responsibility for NetBIOS datagram
distribution.
Interoperability between different implementations is assured by
imposing requirements on end-node implementations that they be able
to accept the full range of legal responses from the NBNS or NBDD.
11.1. NetBIOS NAME SERVER (NBNS) NODES
The NBNS is designed to allow considerable flexibility with its
degree of responsibility for the accuracy and management of NetBIOS
names. On one hand, the NBNS may elect not to accept full
responsibility, leaving the NBNS essentially a "bulletin board" on
which name/address information is freely posted (and removed) by P
and M nodes without validation by the NBNS. Alternatively, the NBNS
may elect to completely manage and validate names. The degree of
responsibility that the NBNS assumes is asserted by the NBNS each
time a name is claimed through a simple mechanism. Should the NBNS
not assert full control, the NBNS returns enough information to the
requesting node so that the node may challenge any putative holder of
the name.
This ability to shift responsibility for NetBIOS name management
between the NBNS and the P and M nodes allows a network administrator
(or vendor) to make a tradeoff between NBNS simplicity, security, and
delay characteristics.
A single NBNS may be implemented as a distributed entity, such as the
Domain Name Service. However, this RFC does not attempt to define
NetBIOS Working Group [Page 18]
RFC 1001 March 1987
the internal communications which would be used.
11.1.1. RELATIONSHIP OF THE NBNS TO THE DOMAIN NAME SYSTEM
The NBNS design attempts to align itself with the Domain Name System
in a number of ways.
First, the NetBIOS names are encoded in a form acceptable to the
domain name system.
Second, a scope identifier is appended to each NetBIOS name. This
identifier meets the restricted character set of the domain system
and has a leading period. This makes the NetBIOS name, in
conjunction with its scope identifier, a valid domain system name.
Third, the negotiated responsibility mechanisms permit the NBNS to be
used as a simple bulletin board on which are posted (name,address)
pairs. This parallels the existing domain sytem query service.
This RFC, however, requires the NBNS to provide services beyond those
provided by the current domain name system. An attempt has been made
to coalesce all the additional services which are required into a set
of transactions which follow domain name system styles of interaction
and packet formats.
Among the areas in which the domain name service must be extended
before it may be used as an NBNS are:
- Dynamic addition of entries
- Dynamic update of entry data
- Support for multiple instance (group) entries
- Support for entry time-to-live values and ability to accept
refresh messages to restart the time-to-live period
- New entry attributes
11.2. NetBIOS DATAGRAM DISTRIBUTION SERVER (NBDD) NODES
The internet does not yet support broadcasting or multicasting. The
NBDD extends NetBIOS datagram distribution service to this
environment.
The NBDD may elect to complete, partially complete, or totally refuse
to service a node's request to distribute a NetBIOS datagram. An
end-node may query an NBDD to determine whether the NBDD will deliver
a datagram to a specific NetBIOS name.
The design of NetBIOS-over-TCP lends itself to the use of Internet
Group Multicast. For details see Appendix A.
NetBIOS Working Group [Page 19]
RFC 1001 March 1987
11.3. RELATIONSHIP OF NBNS AND NBDD NODES
This RFC defines the NBNS and NBDD as distinct, separate entities.
In the absence of NetBIOS name information, a NetBIOS datagram
distribution server must send a copy to each end-node within a
NetBIOS scope.
An implementer may elect to construct NBNS and NBDD nodes which have
a private protocol for the exchange of NetBIOS name information.
Alternatively, an NBNS and NBDD may be implemented within the same
device.
NOTE: Implementations containing private NBNS-NBDD protocols or
combined NBNS-NBDD functions must be clearly identified.
11.4. RELATIONSHIP OF NetBIOS SUPPORT SERVERS AND B NODES
As defined in this RFC, neither NBNS nor NBDD nodes interact with B
nodes. NetBIOS servers do not listen to broadcast traffic on any
broadcast area to which they may be attached. Nor are the NetBIOS
support servers even aware of B node activities or names claimed or
used by B nodes.
It may be possible to extend both the NBNS and NBDD so that they
participate in B node activities and act as a bridge to P and M
nodes. However, such extensions are beyond the scope of this
specification.
12. TOPOLOGIES
B, P, M, NBNS, and NBDD nodes may be combined in various ways to form
useful NetBIOS environments. This section describes some of these
combinations.
There are three classes of operation:
- Class 0: B nodes only.
- Class 1: P nodes only.
- Class 2: P and M nodes together.
In the drawings which follow, any P node may be replaced by an M
node. The effects of such replacement will be mentioned in
conjunction with each example below.
12.1. LOCAL
A NetBIOS scope is operating locally when all entities are within the
same broadcast area.
NetBIOS Working Group [Page 20]
RFC 1001 March 1987
12.1.1. B NODES ONLY
Local operation with only B nodes is the most basic mode of
operation. Name registration and discovery procedures use broadcast
mechanisms. The NetBIOS scope is limited by the extent of the
broadcast area. This configuration does not require NetBIOS support
servers.
====+=========+=====BROADCAST AREA=====+==========+=========+====
| | | | |
| | | | |
+--+--+ +--+--+ +--+--+ +--+--+ +--+--+
| B | | B | | B | | B | | B |
+-----+ +-----+ +-----+ +-----+ +-----+
12.1.2. P NODES ONLY
This configuration would typically be used when the network
administrator desires to eliminate NetBIOS as a source of broadcast
activity.
====+=========+==========+=B'CAST AREA=+==========+=========+====
| | | | | |
| | | | | |
+--+--+ +--+--+ +--+--+ +--+--+ +--+--+ +--+--+
| P | | P | |NBNS | | P | |NBDD | | P |
+-----+ +-----+ +-----+ +-----+ +-----+ +-----+
This configuration operates the same as if it were in an internet and
is cited here only due to its convenience as a means to reduce the
use of broadcast.
Replacement of one or more of the P nodes with M nodes will not
affect the operation of the other P and M nodes. P and M nodes will
be able to interact with one another. Because M nodes use broadcast,
overall broadcast activity will increase.
12.1.3. MIXED B AND P NODES
B and P nodes do not interact with one another. Replacement of P
nodes with M nodes will allow B's and M's to interact.
NOTE: B nodes and M nodes may be intermixed only on a local
broadcast area. B and M nodes should not be intermixed in
an internet environment.
NetBIOS Working Group [Page 21]
RFC 1001 March 1987
12.2. INTERNET
12.2.1. P NODES ONLY
P nodes may be scattered at various locations in an internetwork.
They require both an NBNS and an NBDD for NetBIOS name and datagram
support, respectively.
The NetBIOS scope is determined by the NetBIOS scope identifier
(domain name) used by the various P (and M) nodes. An internet may
contain numerous NetBIOS scopes.
+-----+
| P |
+--+--+ | +-----+
| |----+ P |
| | +-----+
/-----+-----\ |
+-----+ | | +------+ | +-----+
| P +------+ INTERNET +--+G'WAY |-+----+ P |
+-----+ | | +------+ | +-----+
/-----+-----/ |
/ | | +-----+
/ | |----+ P |
+-----+ +--+--+ | +-----+
|NBNS + |NBDD |
+-----+ +--+--+
Any P node may be replaced by an M node with no loss of function to
any node. However, broadcast activity will be increased in the
broadcast area to which the M node is attached.
NetBIOS Working Group [Page 22]
RFC 1001 March 1987
12.2.2. MIXED M AND P NODES
M and P nodes may be mixed. When locating NetBIOS names, M nodes
will tend to find names held by other M nodes on the same common
broadcast area in preference to names held by P nodes or M nodes
elsewhere in the network.
+-----+
| P |
+--+--+
|
|
/-----+-----\
+-----+ | | +-----+
| P +------+ INTERNET +------+NBDD |
+-----+ | | +-----+
/-----+-----/
/ |
/ |
+-----+ +--+--+
|NBNS + |G'WAY|
+-----+ +--+--+
|
|
====+=========+==========+=B'CAST AREA=+==========+=========+====
| | | | | |
| | | | | |
+--+--+ +--+--+ +--+--+ +--+--+ +--+--+ +--+--+
| M | | P | | M | | P | | M | | P |
+-----+ +-----+ +--+--+ +-----+ +-----+ +-----+
NOTE: B and M nodes should not be intermixed in an internet
environment. Doing so would allow undetected NetBIOS name
conflicts to arise and cause unpredictable behavior.
13. GENERAL METHODS
Overlying the specific protocols, described later, are a few general
methods of interaction between entities.
13.1. REQUEST/RESPONSE INTERACTION STYLE
Most interactions between entities consist of a request flowing in
one direction and a subsequent response flowing in the opposite
direction.
In those situations where interactions occur on unreliable transports
(i.e. UDP) or when a request is broadcast, there may not be a strict
interlocking or one-to-one relationship between requests and
responses.
NetBIOS Working Group [Page 23]
RFC 1001 March 1987
In no case, however, is more than one response generated for a
received request. While a response is pending the responding entity
may send one or more wait acknowledgements.
13.1.1. RETRANSMISSION OF REQUESTS
UDP is an unreliable delivery mechanism where packets can be lost,
received out of transmit sequence, duplicated and delivery can be
significantly delayed. Since the NetBIOS protocols make heavy use of
UDP, they have compensated for its unreliability with extra
mechanisms.
Each NetBIOS packet contains all the necessary information to process
it. None of the protocols use multiple UDP packets to convey a
single request or response. If more information is required than
will fit in a single UDP packet, for example, when a P-type node
wants all the owners of a group name from a NetBIOS server, a TCP
connection is used. Consequently, the NetBIOS protocols will not
fail because of out of sequence delivery of UDP packets.
To overcome the loss of a request or response packet, each request
operation will retransmit the request if a response is not received
within a specified time limit.
Protocol operations sensitive to successive response packets, such as
name conflict detection, are protected from duplicated packets
because they ignore successive packets with the same NetBIOS
information. Since no state on the responder's node is associated
with a request, the responder just sends the appropriate response
whenever a request packet arrives. Consequently, duplicate or
delayed request packets have no impact.
For all requests, if a response packet is delayed too long another
request packet will be transmitted. A second response packet being
sent in response to the second request packet is equivalent to a
duplicate packet. Therefore, the protocols will ignore the second
packet received. If the delivery of a response is delayed until
after the request operation has been completed, successfully or not,
the response packet is ignored.
13.1.2. REQUESTS WITHOUT RESPONSES: DEMANDS
Some request types do not have matching responses. These requests
are known as "demands". In general a "demand" is an imperative
request; the receiving node is expected to obey. However, because
demands are unconfirmed, they are used only in situations where, at
most, limited damage would occur if the demand packet should be lost.
Demand packets are not retransmitted.
NetBIOS Working Group [Page 24]
RFC 1001 March 1987
13.2. TRANSACTIONS
Interactions between a pair of entities are grouped into
"transactions". These transactions comprise one or more
request/response pairs.
13.2.1. TRANSACTION ID
Since multiple simultaneous transactions may be in progress between a
pair of entities a "transaction id" is used.
The originator of a transaction selects an ID unique to the
originator. The transaction id is reflected back and forth in each
interaction within the transaction. The transaction partners must
match responses and requests by comparison of the transaction ID and
the IP address of the transaction partner. If no matching request
can be found the response must be discarded.
A new transaction ID should be used for each transaction. A simple
16 bit transaction counter ought to be an adequate id generator. It
is probably not necessary to search the space of outstanding
transaction ID to filter duplicates: it is extremely unlikely that
any transaction will have a lifetime that is more than a small
fraction of the typical counter cycle period. Use of the IP
addresses in conjunction with the transaction ID further reduces the
possibility of damage should transaction IDs be prematurely re-used.
13.3. TCP AND UDP FOUNDATIONS
This version of the NetBIOS-over-TCP protocols uses UDP for many
interactions. In the future this RFC may be extended to permit such
interactions to occur over TCP connections (perhaps to increase
efficiency when multiple interactions occur within a short time or
when NetBIOS datagram traffic reveals that an application is using
NetBIOS datagrams to support connection- oriented service.)
14. REPRESENTATION OF NETBIOS NAMES
NetBIOS names as seen across the client interface to NetBIOS are
exactly 16 bytes long. Within the NetBIOS-over-TCP protocols, a
longer representation is used.
There are two levels of encoding. The first level maps a NetBIOS
name into a domain system name. The second level maps the domain
system name into the "compressed" representation required for
interaction with the domain name system.
Except in one packet, the second level representation is the only
NetBIOS name representation used in NetBIOS-over-TCP packet formats.
The exception is the RDATA field of a NODE STATUS RESPONSE packet.
NetBIOS Working Group [Page 25]
RFC 1001 March 1987
14.1. FIRST LEVEL ENCODING
The first level representation consists of two parts:
- NetBIOS name
- NetBIOS scope identifier
The 16 byte NetBIOS name is mapped into a 32 byte wide field using a
reversible, half-ASCII, biased encoding. Each half-octet of the
NetBIOS name is encoded into one byte of the 32 byte field. The
first half octet is encoded into the first byte, the second half-
octet into the second byte, etc.
Each 4-bit, half-octet of the NetBIOS name is treated as an 8-bit,
right-adjusted, zero-filled binary number. This number is added to
value of the ASCII character 'A' (hexidecimal 41). The resulting 8-
bit number is stored in the appropriate byte. The following diagram
demonstrates this procedure:
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|a b c d|w x y z| ORIGINAL BYTE
+-+-+-+-+-+-+-+-+
| |
+--------+ +--------+
| | SPLIT THE NIBBLES
v v
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
|0 0 0 0 a b c d| |0 0 0 0 w x y z|
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| |
+ + ADD 'A'
| |
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
|0 1 0 0 0 0 0 1| |0 1 0 0 0 0 0 1|
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
This encoding results in a NetBIOS name being represented as a
sequence of 32 ASCII, upper-case characters from the set
{A,B,C...N,O,P}.
The NetBIOS scope identifier is a valid domain name (without a
leading dot).
An ASCII dot (2E hexidecimal) and the scope identifier are appended
to the encoded form of the NetBIOS name, the result forming a valid
domain name.
NetBIOS Working Group [Page 26]
RFC 1001 March 1987
For example, the NetBIOS name "The NetBIOS name" in the NetBIOS scope
"SCOPE.ID.COM" would be represented at level one by the ASCII
character string:
FEGHGFCAEOGFHEECEJEPFDCAHEGBGNGF.SCOPE.ID.COM
14.2. SECOND LEVEL ENCODING
The first level encoding must be reduced to second level encoding.
This is performed according to the rules defined in on page 31 of RFC
883[12] in the section on "Domain name representation and
compression". Also see the section titled "Name Formats" in the
Detailed Specifications[1].
15. NetBIOS NAME SERVICE
Before a name may be used, the name must be registered by a node.
Once acquired, the name must be defended against inconsistent
registration by other nodes. Before building a NetBIOS session or
sending a NetBIOS datagram, the one or more holders of the name must
be located.
The NetBIOS name service is the collection of procedures through
which nodes acquire, defend, and locate the holders of NetBIOS names.
The name service procedures are different depending whether the end-
node is of type B, P, or M.
15.1. OVERVIEW OF NetBIOS NAME SERVICE
15.1.1. NAME REGISTRATION (CLAIM)
Each NetBIOS node can own more than one name. Names are acquired
dynamically through the registration (name claim) procedures.
Every node has a permanent unique name. This name, like any other
name, must be explicitly registered by all end-node types.
A name can be unique (exclusive) or group (non-exclusive). A unique
name may be owned by a single node; a group name may be owned by any
number of nodes. A name ceases to exist when it is not owned by at
least one node. There is no intrinsic quality of a name which
determines its characteristics: these are established at the time of
registration.
Each node maintains state information for each name it has
registered. This information includes:
- Whether the name is a group or unique name
- Whether the name is "in conflict"
- Whether the name is in the process of being deleted
NetBIOS Working Group [Page 27]
RFC 1001 March 1987
B nodes perform name registration by broadcasting claim requests,
soliciting a defense from any node already holding the name.
P nodes perform name registration through the agency of the NBNS.
M nodes register names through an initial broadcast, like B nodes,
then, in the absence of an objection, by following the same
procedures as a P node. In other words, the broadcast action may
terminate the attempt, but is not sufficient to confirm the
registration.
15.1.2. NAME QUERY (DISCOVERY)
Name query (also known as "resolution" or "discovery") is the
procedure by which the IP address(es) associated with a NetBIOS name
are discovered. Name query is required during the following
operations:
During session establishment, calling and called names must be
specified. The calling name must exist on the node that posts the
CALL. The called name must exist on a node that has previously
posted a LISTEN. Either name may be a unique or group name.
When a directed datagram is sent, a source and destination name must
be specified. If the destination name is a group name, a datagram is
sent to all the members of that group.
Different end-node types perform name resolution using different
techniques, but using the same packet formats:
- B nodes solicit name information by broadcasting a request.
- P nodes ask the NBNS.
- M nodes broadcast a request. If that does not provide the
desired information, an inquiry is sent to the NBNS.
15.1.3. NAME RELEASE
NetBIOS names may be released explicitly or silently by an end- node.
Silent release typically occurs when an end-node fails or is turned-
off. Most of the mechanisms described below are present to detect
silent name release.
15.1.3.1. EXPLICIT RELEASE
B nodes explicitly release a name by broadcasting a notice.
P nodes send a notification to their NBNS.
M nodes both broadcast a notice and inform their supporting NBNS.
NetBIOS Working Group [Page 28]
RFC 1001 March 1987
15.1.3.2. NAME LIFETIME AND REFRESH
Names held by an NBNS are given a lifetime during name registration.
The NBNS will consider a name to have been silently released if the
end-node fails to send a name refresh message to the NBNS before the
lifetime expires. A refresh restarts the lifetime clock.
NOTE: The implementor should be aware of the tradeoff between
accuracy of the database and the internet overhead that the
refresh mechanism introduces. The lifetime period should
be tuned accordingly.
For group names, each end-node must send refresh messages. A node
that fails to do so will be considered to have silently released the
name and dropped from the group.
The lifetime period is established through a simple negotiation
mechanism during name registration: In the name registration
request, the end-node proposes a lifetime value or requests an
infinite lifetime. The NBNS places an actual lifetime value into the
name registration response. The NBNS is always allowed to respond
with an inf