As per Relevance of the word broadcast, we have this rfc below:
Network Working
Request for Comments: 1001 March, 1987
PROTOCOL STANDARD FOR A NetBIOS
ON A TCP/UDP TRANSPORT
CONCEPTS AND
This RFC defines a proposed standard protocol to support
services in a TCP/IP environment. Both local network and
operation are supported. Various node types are defined to
local and internet topologies and to allow operation with or without
use of IP broadcast
This RFC describes the NetBIOS-over-TCP protocols in a general manner
emphasizing the underlying ideas and techniques.
specifications are found in a companion RFC, "Protocol Standard For
NetBIOS Service on a TCP/UDP Transport: Detailed Specifications".
NetBIOS Working Group [Page 1]
RFC 1001 March 1987
SUMMARY OF
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
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
ON A TCP/UDP TRANSPORT
CONCEPTS AND
1. STATUS OF THIS
This RFC specifies a proposed standard for the
community. Since this topic is new to the Internet community
discussions and suggestions are specifically requested
Please send written comments to
Karl
Epilogue Technology
P.O. Box 5432
Redwood City, CA 94063
Please send online comments to
Avnish
Internet: mtxinu!excelan!avnish@ucbvax.berkeley.
Usenet: ucbvax!mtxinu!excelan!
Distribution of this document is unlimited
2.
This RFC has been developed under the auspices of the
Activities Board, especially the End-to-End Services Task Force
The following individuals have contributed to the development
this RFC
Avnish Aggarwal Arvind Agrawal Lorenzo
Geoffrey Arnold Karl Auerbach K. Ramesh
Keith Ball Amatzia Ben-Artzi Vint
Richard Cherry David Crocker Steve
Greg Ennis Steve Holmgren Jay
David Kaufman Lee LaBarre James
Dan Lynch Gaylord Miyata David
Steve Thomas Ishan
The system proposed by this RFC does not reflect any
Netbios-over-TCP implementation. However, the
incorporates considerable knowledge obtained from
implementations. Special thanks goes to the
organizations which have provided this invaluable information
CMC/Syros Excelan Sytek Ungermann-
NetBIOS Working Group [Page 6]
RFC 1001 March 1987
3.
This RFC describes the ideas and general methods used to
NetBIOS on a TCP and UDP foundation. A companion RFC, "
Standard For a NetBIOS Service on a TCP/UDP Transport:
Specifications"[1] contains detailed descriptions of
formats, protocols, and defined constants and variables
The NetBIOS service has become the dominant mechanism
personal computer networking. NetBIOS provides a
independent interface for the IBM Personal Computer (PC)
compatible systems
NetBIOS defines a software interface not a protocol. There is
"official" NetBIOS service standard. In practice, however,
IBM PC-Network version is used as a reference. That version
described in the IBM document 6322916, "Technical Reference
Network"[2].
Protocols supporting NetBIOS services have been constructed
diverse protocol and hardware foundations. Even when the
foundation is used, different implementations may not be able
interoperate unless they use a common protocol. To allow
interoperation in the Internet, this RFC defines a
protocol to support NetBIOS services using TCP and UDP
NetBIOS has generally been confined to personal computers
date. However, since larger computers are often well suited
run certain NetBIOS applications, such as file servers,
specification has been designed to allow an implementation to
built on virtually any type of system where the TCP/IP
suite is available
This standard defines a set of protocols to support
services
These protocols are more than a simple communications
involving two entities. Rather, this note describes
distributed system in which many entities play a part even
they are not involved as an end-point of a particular
connection
This standard neither constrains nor determines how
services are presented to application programs
Nevertheless, it is expected that on computers operating
the PC-DOS and MS-DOS operating systems that the existing
interface will be preserved by implementors
NOTE: Various symbolic values are used in this document.
their definitions, refer to the Detailed Specifications[1].
NetBIOS Working Group [Page 7]
RFC 1001 March 1987
4. DESIGN
In order to develop the specification the following design
were adopted to guide the effort. Most are typical to any
standardization effort; however, some have been assigned
that may be considered unusual
4.1. PRESERVE NetBIOS
In the absence of an "official" standard for NetBIOS services,
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
extend them beyond personal computers into larger hosts. To
these applications, NetBIOS on TCP must closely conform to
services offered by existing NetBIOS systems
IBM PC-Network NetBIOS contains some implementation
characteristics. This standard does not attempt to
preserve these. It is certain that some existing software
these characteristics and will fail to operate correctly on a
service based on this RFC
4.2. USE EXISTING
Protocol development, especially with standardization, is a
process. The development of new protocols must be minimized
It is considered essential that an existing standard which
the necessary functionality with reasonable performance always
chosen in preference to developing a new protocol
When a standard protocol is used, it must be unmodified
4.3. MINIMIZE
The standard for NetBIOS on TCP should contain few, if any, options
Where options are included, the options should be designed so
devices with different option selections should interoperate
4.4. TOLERATE ERRORS AND
NetBIOS networks typically operate in an uncontrolled environment
Computers come on-line at arbitrary times. Computers usually
off-line without any notice to their peers. The software is
operated by users who are unfamiliar with networks and who
randomly perturb configuration settings
Despite this chaos, NetBIOS networks work. NetBIOS on TCP must
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
against all disruptions. A typical NetBIOS network may be
by certain types of behavior, whether inadvertent or malicious
4.5. DO NOT REQUIRE CENTRAL
NetBIOS on TCP should be able to operate, if desired,
centralized management beyond that typically required by a TCP
network
4.6. ALLOW INTERNET
The proposed standard recognizes the need for NetBIOS
across a set of networks interconnected by network (IP) level
(gateways.)
However, the standard assumes that this form of operation will
less frequent than on the local MAC bridged-LAN
4.7. MINIMIZE BROADCAST
The standard pre-supposes that the only broadcast services are
supported by UDP. Multicast capabilities are not assumed to
available in any form
Despite the availability of broadcast capabilities, the
recognizes that some administrations may wish to avoid
broadcast activity. For example, an administration may wish to
isolated non-participating hosts from the burden of receiving
discarding NetBIOS broadcasts
4.8. PERMIT IMPLEMENTATION ON EXISTING
The NetBIOS on TCP protocol should be implementable on
operating systems, such as Unix(tm) and VAX/VMS(tm), without
effort
The NetBIOS protocols should not require services
unavailable on presently existing TCP/UDP/IP implementations
4.9. REQUIRE ONLY THE MINIMUM NECESSARY TO
The protocol definition should specify only the minimal set
protocols required for interoperation. However, additional
elements may be defined to enhance efficiency. These latter
may be generated at the option of the sender, although they must
accepted by all receivers
NetBIOS Working Group [Page 9]
RFC 1001 March 1987
4.10. MAXIMIZE
To be useful, a protocol must conduct its business quickly
4.11. MINIMIZE NEW
When an existing protocol is not quite able to support a
function, but with a small amount of change, it could, that
should be used. This is felt to be easier to achieve
development of new protocols; further, it is likely to have
general utility for the Internet
5. OVERVIEW OF
This section describes the NetBIOS services. It is for
information only. The reader may chose to skip to the next section
NetBIOS was designed for use by groups of PCs, sharing a
medium. Both connection (Session) and connectionless (Datagram
services are provided, and broadcast and multicast are supported
Participants are identified by name. Assignment of names
distributed and highly dynamic
NetBIOS applications employ NetBIOS mechanisms to locate resources
establish connections, send and receive data with an
peer, and terminate connections. For purposes of discussion,
mechanisms will collectively be called the NetBIOS Service
This service can be implemented in many different ways. One of
first implementations was for personal computers running the PC-
and MS-DOS operating systems. It is possible to implement
within other operating systems, or as processes which are
themselves, simply application programs as far as the host
system is concerned
The NetBIOS specification, published by IBM as "Technical
PC Network"[2] defines the interface and services available to
NetBIOS user. The protocols outlined by that document pertain
to the IBM PC Network and are not generally applicable to
networks
5.1. INTERFACE TO APPLICATION
NetBIOS on personal computers includes both a set of services and
exact program interface to those services. NetBIOS on other
systems may present the NetBIOS services to programs using
interfaces. Except on personal computers, no clear standard for
NetBIOS software interface has emerged
NetBIOS Working Group [Page 10]
RFC 1001 March 1987
5.2. NAME
NetBIOS resources are referenced by name. Lower-level
information is not available to NetBIOS applications.
application, representing a resource, registers one or more
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
exclusive (unique) or shared (group) ownership. Each
contends with the other applications in real time.
permission is granted to a station when it receives no objections
That is, a bid is made and the application waits for a period
time. If no objections are received, the station assumes that it
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
may remove a name. Implicit name deletion occurs when a
ceases operation. In the case of personal computers, implicit
deletion is a frequent occurrence
The Name Service primitives are
1) Add
The requesting application wants exclusive use of the name
2) Add Group
The requesting application is willing to share use of
name with other applications
3) Delete
The application no longer requires use of the name. It
important to note that typical use of NetBIOS is
independently-operated personal computers. A common way
stop using a PC is to turn it off; in this case,
graceful give-back mechanism, provided by the Delete
function, is not used. Because this occurs frequently,
network service must support this behavior
NetBIOS Working Group [Page 11]
RFC 1001 March 1987
5.3. SESSION
A session is a reliable message exchange, conducted between a pair
NetBIOS applications. Sessions are full-duplex, sequenced,
reliable. Data is organized into messages. Each message may
in size from 0 to 131,071 bytes. No expedited or urgent
capabilities are present
Multiple sessions may exist between any pair of calling and
names
The parties to a connection have access to the calling and
names
The NetBIOS specification does not define how a connection request
a shared (group) name resolves into a session. The usual
is that a session may be established with any one owner of the
group name
An important service provided to NetBIOS applications is
detection of sessions failure. The loss of a session is reported
an application via all of the outstanding service requests for
session. For example, if the application has only a NetBIOS
primitive pending and the session terminates, the pending
will abort with a termination indication
Session Service primitives are
1)
Initiate a session with a process that is listening
the specified name. The calling entity must indicate both
calling name (properly registered to the caller) and
called name
2)
Accept a session from a caller. The listen primitive may
constrained to accept an incoming call from a named caller
Alternatively, a call may be accepted from any caller
3) Hang
Gracefully terminate a session. All pending data
transferred before the session is terminated
4)
Transmit one message. A time-out can occur. A time-out
any session send forces the non-graceful termination of
session
NetBIOS Working Group [Page 12]
RFC 1001 March 1987
A "chain send" primitive is required by the PC
software interface to allow a single message to be
from pieces in various buffers. Chain Send is an
detail and does not effect the protocol
5)
Receive data. A time-out can occur. A time-out on
session receive only terminates the receive, not
session, although the data is lost
The receive primitive may be implemented with variants,
as "Receive Any", which is required by the PC
software interface. Receive Any is an interface detail
does not effect the protocol
6) Session
Obtain information about all of the requestor's sessions
under the specified name. No network activity is involved
5.4. DATAGRAM
The Datagram service is an unreliable, non-sequenced,
service. Datagrams are sent under cover of a name
registered to the sender
Datagrams may be sent to a specific name or may be
broadcast
Datagrams sent to an exclusive name are received, if at all, by
holder of that name. Datagrams sent to a group name are multicast
all holders of that name. The sending application program
distinguish between group and unique names and thus must act as
all non-broadcast datagrams are multicast
As with the Session Service, the receiver of the datagram is told
sending and receiving names
Datagram Service primitives are
1) Send
Send an unreliable datagram to an application that
associated with the specified name. The name may be
or group; the sender is not aware of the difference. If
name belongs to a group, then each member is to receive
datagram
NetBIOS Working Group [Page 13]
RFC 1001 March 1987
2) Send Broadcast
Send an unreliable datagram to any application with
Receive Broadcast Datagram posted
3) Receive
Receive a datagram sent by a specified originating name
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
Receiving Datagrams that have source and
specifications matching those of the datagram. In
words, if a program (or group of programs) issue a series
identical Receive Datagrams, one datagram will cause
entire series to complete
4) Receive Broadcast
Receive a datagram sent as a broadcast
If there are multiple pending Receive Broadcast
operations pending, all will be satisfied by the
received datagram
5.5. MISCELLANEOUS
The following functions are present to control the operation of
hardware interface to the network. These functions are
implementation dependent
1)
Initialize the local network adapter
2)
Abort a pending NetBIOS request. The successful cancel of
Send (or Chain Send) operation will terminate the
session
3) Adapter
Obtain information about the local network adapter or of
remote adapter
4)
For use with Remote Program Load (RPL). Unlink
the PC boot disk device back to the local disk. See
NetBIOS Working Group [Page 14]
RFC 1001 March 1987
NetBIOS specification for further details concerning RPL
the Unlink operation (see page 2-35 in [2]).
5) Remote Program
Remote Program Load (RPL) is not a NetBIOS function. It
a NetBIOS application defined by IBM in their
specification (see pages 2-80 through 2-82 in [2]).
5.6. NON-STANDARD
The IBM Token Ring implementation of NetBIOS has added at least
new user capability
1) Find
This function determines whether a given name has
registered on the network
6. NetBIOS FACILITIES SUPPORTED BY THIS
The protocol specified by this standard permits an implementer
provide all of the NetBIOS services as described in the
"Technical Reference PC Network"[2].
The following NetBIOS facilities are outside the scope of
specification. These are local implementation matters and do
impact interoperability
-
- SESSION
-
- RPL (Remote Program Load
7. REQUIRED SUPPORTING SERVICE INTERFACES AND
The protocols described in this RFC require service interfaces to
following
- TCP[3,4]
- UDP[5]
Byte ordering, addressing conventions (including addresses to
used for broadcasts and multicasts) are defined by the
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
The design of the protocols described in this RFC allow for
future incorporation of the following protocols and services
However, before this may occur, certain extensions may be required
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
A "NetBIOS Scope" is the population of computers across which
registered NetBIOS name is known. NetBIOS broadcast and
datagram operations must reach the entire extent of the
scope
An internet may support multiple, non-intersecting NetBIOS Scopes
Each NetBIOS scope has a "scope identifier". This identifier is
character string meeting the requirements of the domain name
for domain names
NOTE: Each implementation of NetBIOS-over-TCP must
mechanisms to manage the scope identifier(s) to be used
Control of scope identifiers implies a requirement for
NetBIOS interface capabilities. These may be provided
extensions of the user service interface or other means (such as
configuration parameters.) The nature of these extensions is
part of this specification
10. NetBIOS END-
End-nodes support NetBIOS service interfaces and
applications
Three types of end-nodes are part of this standard
- Broadcast ("B")
- Point-to-point ("P")
- Mixed mode ("M")
An IP address may be associated with only one instance of one of
above types
Without having preloaded name-to-address tables, NetBIOS
NetBIOS Working Group [Page 16]
RFC 1001 March 1987
are faced with the task of dynamically resolving references to
another. This can be accomplished with broadcast or mediated point
to-point communications
B nodes use local network broadcasting to effect a rendezvous
one or more recipients. P and M nodes use the NetBIOS Name
(NBNS) and the NetBIOS Datagram Distribution Server (NBDD) for
same purpose
End-nodes may be combined in various topologies. No matter
combined, the operation of the B, P, and M nodes is not altered
NOTE: It is recommended that the administration of a
scope avoid using both M and B nodes within the same scope
A NetBIOS scope should contain only B nodes or only P and
nodes
10.1. BROADCAST (B)
Broadcast (or "B") nodes communicate using a mix of UDP
(both broadcast and directed) and TCP connections. B nodes
freely interoperate with one another within a broadcast area.
broadcast area is a single MAC-bridged "B-LAN". (See Appendix A
a discussion of using Internet Group Multicasting as a means
extend a broadcast area beyond a single B-LAN.)
10.2. POINT-TO-POINT (P)
Point-to-point (or "P") nodes communicate using only directed
datagrams and TCP sessions. P nodes neither generate nor listen
broadcast UDP packets. P nodes do, however, offer NetBIOS
broadcast and multicast services using capabilities provided by
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
either case
10.3. MIXED MODE (M)
Mixed mode nodes (or "M") nodes are P nodes which have been
certain B node characteristics. M nodes use both broadcast
unicast. Broadcast is used to improve response time using
assumption that most resources reside on the local broadcast
rather than somewhere in an internet
M nodes rely upon NBNS and NBDD servers. However, M nodes
continue limited operation should these servers be
unavailable
NetBIOS Working Group [Page 17]
RFC 1001 March 1987
11. NetBIOS SUPPORT
Two types of support servers are part of this standard
- NetBIOS name server ("NBNS")
- Netbios datagram distribution ("NBDD")
NBNS and NBDD nodes are invisible to NetBIOS applications and
part of the underlying NetBIOS mechanism
NetBIOS name and datagram distribution servers are the focus of
and datagram activity for P and M nodes
Both the name (NBNS) and datagram distribution (NBDD) servers
permitted to shift part of their operation to the P or M end-
which is requesting a service
Since the assignment of responsibility is dynamic, and since P and
nodes must be prepared to operate should the NetBIOS server
control to the maximum extent, the system naturally
improvements in NetBIOS server function. For example, as
Group Multicasting becomes more widespread, new NBDD
may elect to assume full responsibility for NetBIOS
distribution
Interoperability between different implementations is assured
imposing requirements on end-node implementations that they be
to accept the full range of legal responses from the NBNS or NBDD
11.1. NetBIOS NAME SERVER (NBNS)
The NBNS is designed to allow considerable flexibility with
degree of responsibility for the accuracy and management of
names. On one hand, the NBNS may elect not to accept
responsibility, leaving the NBNS essentially a "bulletin board"
which name/address information is freely posted (and removed) by
and M nodes without validation by the NBNS. Alternatively, the
may elect to completely manage and validate names. The degree
responsibility that the NBNS assumes is asserted by the NBNS
time a name is claimed through a simple mechanism. Should the
not assert full control, the NBNS returns enough information to
requesting node so that the node may challenge any putative holder
the name
This ability to shift responsibility for NetBIOS name
between the NBNS and the P and M nodes allows a network
(or vendor) to make a tradeoff between NBNS simplicity, security,
delay characteristics
A single NBNS may be implemented as a distributed entity, such as
Domain Name Service. However, this RFC does not attempt to
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
The NBNS design attempts to align itself with the Domain Name
in a number of ways
First, the NetBIOS names are encoded in a form acceptable to
domain name system
Second, a scope identifier is appended to each NetBIOS name.
identifier meets the restricted character set of the domain
and has a leading period. This makes the NetBIOS name,
conjunction with its scope identifier, a valid domain system name
Third, the negotiated responsibility mechanisms permit the NBNS to
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
provided by the current domain name system. An attempt has been
to coalesce all the additional services which are required into a
of transactions which follow domain name system styles of
and packet formats
Among the areas in which the domain name service must be
before it may be used as an NBNS are
- Dynamic addition of
- Dynamic update of entry
- Support for multiple instance (group)
- Support for entry time-to-live values and ability to
refresh messages to restart the time-to-live
- New entry
11.2. NetBIOS DATAGRAM DISTRIBUTION SERVER (NBDD)
The internet does not yet support broadcasting or multicasting.
NBDD extends NetBIOS datagram distribution service to
environment
The NBDD may elect to complete, partially complete, or totally
to service a node's request to distribute a NetBIOS datagram.
end-node may query an NBDD to determine whether the NBDD will
a datagram to a specific NetBIOS name
The design of NetBIOS-over-TCP lends itself to the use of
Group Multicast. For details see Appendix A
NetBIOS Working Group [Page 19]
RFC 1001 March 1987
11.3. RELATIONSHIP OF NBNS AND NBDD
This RFC defines the NBNS and NBDD as distinct, separate entities
In the absence of NetBIOS name information, a NetBIOS
distribution server must send a copy to each end-node within
NetBIOS scope
An implementer may elect to construct NBNS and NBDD nodes which
a private protocol for the exchange of NetBIOS name information
Alternatively, an NBNS and NBDD may be implemented within the
device
NOTE: Implementations containing private NBNS-NBDD protocols
combined NBNS-NBDD functions must be clearly identified
11.4. RELATIONSHIP OF NetBIOS SUPPORT SERVERS AND B
As defined in this RFC, neither NBNS nor NBDD nodes interact with
nodes. NetBIOS servers do not listen to broadcast traffic on
broadcast area to which they may be attached. Nor are the
support servers even aware of B node activities or names claimed
used by B nodes
It may be possible to extend both the NBNS and NBDD so that
participate in B node activities and act as a bridge to P and
nodes. However, such extensions are beyond the scope of
specification
12.
B, P, M, NBNS, and NBDD nodes may be combined in various ways to
useful NetBIOS environments. This section describes some of
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
node. The effects of such replacement will be mentioned
conjunction with each example below
12.1.
A NetBIOS scope is operating locally when all entities are within
same broadcast area
NetBIOS Working Group [Page 20]
RFC 1001 March 1987
12.1.1. B NODES
Local operation with only B nodes is the most basic mode
operation. Name registration and discovery procedures use
mechanisms. The NetBIOS scope is limited by the extent of
broadcast area. This configuration does not require NetBIOS
servers
====+=========+=====BROADCAST AREA=====+==========+=========+====
| | | | |
| | | | |
+--+--+ +--+--+ +--+--+ +--+--+ +--+--+
| B | | B | | B | | B | | B |
+-----+ +-----+ +-----+ +-----+ +-----+
12.1.2. P NODES
This configuration would typically be used when the
administrator desires to eliminate NetBIOS as a source of
activity
====+=========+==========+=B'CAST AREA=+==========+=========+====
| | | | | |
| | | | | |
+--+--+ +--+--+ +--+--+ +--+--+ +--+--+ +--+--+
| P | | P | |NBNS | | P | |NBDD | | P |
+-----+ +-----+ +-----+ +-----+ +-----+ +-----+
This configuration operates the same as if it were in an internet
is cited here only due to its convenience as a means to reduce
use of broadcast
Replacement of one or more of the P nodes with M nodes will
affect the operation of the other P and M nodes. P and M nodes
be able to interact with one another. Because M nodes use broadcast
overall broadcast activity will increase
12.1.3. MIXED B AND P
B and P nodes do not interact with one another. Replacement of
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
broadcast area. B and M nodes should not be intermixed
an internet environment
NetBIOS Working Group [Page 21]
RFC 1001 March 1987
12.2.
12.2.1. P NODES
P nodes may be scattered at various locations in an internetwork
They require both an NBNS and an NBDD for NetBIOS name and
support, respectively
The NetBIOS scope is determined by the NetBIOS scope
(domain name) used by the various P (and M) nodes. An internet
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
any node. However, broadcast activity will be increased in
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
M and P nodes may be mixed. When locating NetBIOS names, M
will tend to find names held by other M nodes on the same
broadcast area in preference to names held by P nodes or M
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
environment. Doing so would allow undetected NetBIOS
conflicts to arise and cause unpredictable behavior
13. GENERAL
Overlying the specific protocols, described later, are a few
methods of interaction between entities
13.1. REQUEST/RESPONSE INTERACTION
Most interactions between entities consist of a request flowing
one direction and a subsequent response flowing in the
direction
In those situations where interactions occur on unreliable
(i.e. UDP) or when a request is broadcast, there may not be a
interlocking or one-to-one relationship between requests
responses
NetBIOS Working Group [Page 23]
RFC 1001 March 1987
In no case, however, is more than one response generated for
received request. While a response is pending the responding
may send one or more wait acknowledgements
13.1.1. RETRANSMISSION OF
UDP is an unreliable delivery mechanism where packets can be lost
received out of transmit sequence, duplicated and delivery can
significantly delayed. Since the NetBIOS protocols make heavy use
UDP, they have compensated for its unreliability with
mechanisms
Each NetBIOS packet contains all the necessary information to
it. None of the protocols use multiple UDP packets to convey
single request or response. If more information is required
will fit in a single UDP packet, for example, when a P-type
wants all the owners of a group name from a NetBIOS server, a
connection is used. Consequently, the NetBIOS protocols will
fail because of out of sequence delivery of UDP packets
To overcome the loss of a request or response packet, each
operation will retransmit the request if a response is not
within a specified time limit
Protocol operations sensitive to successive response packets, such
name conflict detection, are protected from duplicated
because they ignore successive packets with the same
information. Since no state on the responder's node is
with a request, the responder just sends the appropriate
whenever a request packet arrives. Consequently, duplicate
delayed request packets have no impact
For all requests, if a response packet is delayed too long
request packet will be transmitted. A second response packet
sent in response to the second request packet is equivalent to
duplicate packet. Therefore, the protocols will ignore the
packet received. If the delivery of a response is delayed
after the request operation has been completed, successfully or not
the response packet is ignored
13.1.2. REQUESTS WITHOUT RESPONSES:
Some request types do not have matching responses. These
are known as "demands". In general a "demand" is an
request; the receiving node is expected to obey. However,
demands are unconfirmed, they are used only in situations where,
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.
Interactions between a pair of entities are grouped
"transactions". These transactions comprise one or
request/response pairs
13.2.1. TRANSACTION
Since multiple simultaneous transactions may be in progress between
pair of entities a "transaction id" is used
The originator of a transaction selects an ID unique to
originator. The transaction id is reflected back and forth in
interaction within the transaction. The transaction partners
match responses and requests by comparison of the transaction ID
the IP address of the transaction partner. If no matching
can be found the response must be discarded
A new transaction ID should be used for each transaction. A
16 bit transaction counter ought to be an adequate id generator.
is probably not necessary to search the space of
transaction ID to filter duplicates: it is extremely unlikely
any transaction will have a lifetime that is more than a
fraction of the typical counter cycle period. Use of the
addresses in conjunction with the transaction ID further reduces
possibility of damage should transaction IDs be prematurely re-used
13.3. TCP AND UDP
This version of the NetBIOS-over-TCP protocols uses UDP for
interactions. In the future this RFC may be extended to permit
interactions to occur over TCP connections (perhaps to
efficiency when multiple interactions occur within a short time
when NetBIOS datagram traffic reveals that an application is
NetBIOS datagrams to support connection- oriented service.)
14. REPRESENTATION OF NETBIOS
NetBIOS names as seen across the client interface to NetBIOS
exactly 16 bytes long. Within the NetBIOS-over-TCP protocols,
longer representation is used
There are two levels of encoding. The first level maps a
name into a domain system name. The second level maps the
system name into the "compressed" representation required
interaction with the domain name system
Except in one packet, the second level representation is the
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
The first level representation consists of two parts
- NetBIOS
- NetBIOS scope
The 16 byte NetBIOS name is mapped into a 32 byte wide field using
reversible, half-ASCII, biased encoding. Each half-octet of
NetBIOS name is encoded into one byte of the 32 byte field.
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
value of the ASCII character 'A' (hexidecimal 41). The resulting 8-
bit number is stored in the appropriate byte. The following
demonstrates this procedure
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|a b c d|w x y z| ORIGINAL
+-+-+-+-+-+-+-+-+
| |
+--------+ +--------+
| | SPLIT THE
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
sequence of 32 ASCII, upper-case characters from the
{A,B,C...N,O,P}.
The NetBIOS scope identifier is a valid domain name (without
leading dot).
An ASCII dot (2E hexidecimal) and the scope identifier are
to the encoded form of the NetBIOS name, the result forming a
domain name
NetBIOS Working Group [Page 26]
RFC 1001 March 1987
For example, the NetBIOS name "The NetBIOS name" in the NetBIOS
"SCOPE.ID.COM" would be represented at level one by the
character string
FEGHGFCAEOGFHEECEJEPFDCAHEGBGNGF.SCOPE.ID.
14.2. SECOND LEVEL
The first level encoding must be reduced to second level encoding
This is performed according to the rules defined in on page 31 of
883[12] in the section on "Domain name representation
compression". Also see the section titled "Name Formats" in
Detailed Specifications[1].
15. NetBIOS NAME
Before a name may be used, the name must be registered by a node
Once acquired, the name must be defended against
registration by other nodes. Before building a NetBIOS session
sending a NetBIOS datagram, the one or more holders of the name
be located
The NetBIOS name service is the collection of procedures
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
15.1.1. NAME REGISTRATION (CLAIM
Each NetBIOS node can own more than one name. Names are
dynamically through the registration (name claim) procedures
Every node has a permanent unique name. This name, like any
name, must be explicitly registered by all end-node types
A name can be unique (exclusive) or group (non-exclusive). A
name may be owned by a single node; a group name may be owned by
number of nodes. A name ceases to exist when it is not owned by
least one node. There is no intrinsic quality of a name
determines its characteristics: these are established at the time
registration
Each node maintains state information for each name it
registered. This information includes
- Whether the name is a group or unique
- Whether the name is "in conflict
- Whether the name is in the process of being
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
procedures as a P node. In other words, the broadcast action
terminate the attempt, but is not sufficient to confirm
registration
15.1.2. NAME QUERY (DISCOVERY
Name query (also known as "resolution" or "discovery") is
procedure by which the IP address(es) associated with a NetBIOS
are discovered. Name query is required during the
operations
During session establishment, calling and called names must
specified. The calling name must exist on the node that posts
CALL. The called name must exist on a node that has
posted a LISTEN. Either name may be a unique or group name
When a directed datagram is sent, a source and destination name
be specified. If the destination name is a group name, a datagram
sent to all the members of that group
Different end-node types perform name resolution using
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
desired information, an inquiry is sent to the NBNS
15.1.3. NAME
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
silent name release
15.1.3.1. EXPLICIT
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
Names held by an NBNS are given a lifetime during name registration
The NBNS will consider a name to have been silently released if
end-node fails to send a name refresh message to the NBNS before
lifetime expires. A refresh restarts the lifetime clock
NOTE: The implementor should be aware of the tradeoff
accuracy of the database and the internet overhead that
refresh mechanism introduces. The lifetime period
be tuned accordingly
For group names, each end-node must send refresh messages. A
that fails to do so will be considered to have silently released
name and dropped from the group
The lifetime period is established through a simple
mechanism during name registration: In the name
request, the end-node proposes a lifetime value or requests
infinite lifetime. The NBNS places an actual lifetime value into
name registration response. The NBNS is always allowed to
with an infinite actual period. If the end node proposed an
lifetime, the NBNS may respond with any definite period. If the
node proposed a definite period, the NBNS may respond with
definite period greater than or equal to that proposed
This negotiation of refresh times gives the NBNS means to disable
enable refresh activity. The end-nodes may set a minimum
cycle period
NBNS implementations which are completely reliable may
refresh
15.1.3.3. NAME
To detect whether a node has silently released its claim to a name
it is necessary on occasion to challenge that node's
ownership. If the node defends the name then the node is allowed
continue possession. Otherwise it is assumed that the node
released the name
A name challenge may be issued by an NBNS or by a P or M node.
challenge may be directed towards any end-node type: B, P, or M
15.1.3.4. GROUP NAME FADE-
NetBIOS groups may contain an arbitrarily large number of members
The time to challenge all members could be quite large
To avoid long delays when names are claimed through an NBNS,
NetBIOS Working Group [Page 29]
RFC 1001 March 1987
optimistic heuristic has been adopted. It is assumed that there
always be some node which will defend a group name. Consequently,
is recommended that the NBNS will immediately reject a claim
for a unique name when there already exists a group with the
name. The NBNS will never return an IP address (in response to
NAME REGISTRATION REQUEST) when a group name exists
An NBNS will consider a group to have faded out of existence when
last remaining member fails to send a timely refresh message
explicitly releases the name
15.1.3.5. NAME
Name conflict exists when a unique name has been claimed by more
one node on a NetBIOS network. B, M, and NBNS nodes may detect
name conflict. The detection mechanism used by B and M nodes
active only during name discovery. The NBNS may detect conflict
any time it verifies the consistency of its name database
B and M nodes detect conflict by examining the responses received
answer to a broadcast name query request. The first response
taken as authoritative. Any subsequent, inconsistent
represent conflicts
Subsequent responses are inconsistent with the authoritative
when
The subsequent response has the same transaction ID as
NAME QUERY REQUEST
The subsequent response is not a duplicate of
authoritative response
AND EITHER
The group/unique characteristic of the
response is "unique".
The group/unique characteristic of the
response is "unique".
The period in which B and M nodes examine responses is limited by
conflict timer, CONFLICT_TIMER. The accuracy or duration of
timer is not crucial: the NetBIOS system will continue to
even with persistent name conflicts
Conflict conditions are signaled by sending a NAME CONFLICT DEMAND
the node owning the offending name. Nothing is sent to the
which originated the authoritative response
Any end-node that receives NAME CONFLICT DEMAND is required to
its "local name table" to reflect that the name is in conflict. (
"local name table" on each node contains names that have
NetBIOS Working Group [Page 30]
RFC 1001 March 1987
successfully registered by that node.)
Notice that only those nodes that receive the name conflict
place a conflict mark next to a name
Logically, a marked name does not exist on that node. This
that the node should not defend the name (for name claim purposes),
should not respond to a name discovery requests for that name,
should the node send name refresh messages for that name
Furthermore, it can no longer be used by that node for any
establishment or sending or receiving datagrams. Existing
are not affected at the time a name is marked as being in conflict
The only valid user function against a marked name is DELETE NAME
Any other user NetBIOS function returns immediately with an
code of "NAME CONFLICT".
15.1.4. ADAPTER
An end-node or the NBNS may ask any other end-node for a
of information about the NetBIOS status of that node. This
consists of, among other things, a list of the names which the
believes it owns. The returned status is filtered to contain
those names which have the same NetBIOS scope identifier as
requestor's name
When requesting node status, the requestor identifies the target
by NetBIOS name A name query transaction may be necessary to
the IP address for the name. Locally cached name information may
used in lieu of a query transaction. The requesting node sends
NODE STATUS REQUEST. In response, the receiving node sends a
STATUS RESPONSE containing its local name table and
statistics
The amount of status which may be returned is limited by the size
a UDP packet. However, this is sufficient for the typical
STATUS RESPONSE packet
15.1.5. END-NODE NBNS
There are certain characteristics of end-node to NBNS
which are in common and are independent of any particular
type
15.1.5.1. UDP, TCP, AND
For all transactions between an end-node and an NBNS, either UDP
TCP may be used as a transport. If the NBNS receives a UDP
request, it will respond using UDP. If the amount of
exceeds what fits into a UDP packet, the response will contain
"truncation flag". In this situation, the end- node may open a
NetBIOS Working Group [Page 31]