summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc1001.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc1001.txt')
-rw-r--r--doc/rfc/rfc1001.txt4010
1 files changed, 4010 insertions, 0 deletions
diff --git a/doc/rfc/rfc1001.txt b/doc/rfc/rfc1001.txt
new file mode 100644
index 0000000..836cad7
--- /dev/null
+++ b/doc/rfc/rfc1001.txt
@@ -0,0 +1,4010 @@
+
+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 infinite actual period. If the end node proposed an infinite
+ lifetime, the NBNS may respond with any definite period. If the end
+ node proposed a definite period, the NBNS may respond with any
+ definite period greater than or equal to that proposed.
+
+ This negotiation of refresh times gives the NBNS means to disable or
+ enable refresh activity. The end-nodes may set a minimum refresh
+ cycle period.
+
+ NBNS implementations which are completely reliable may disable
+ refresh.
+
+15.1.3.3. NAME CHALLENGE
+
+ To detect whether a node has silently released its claim to a name,
+ it is necessary on occasion to challenge that node's current
+ ownership. If the node defends the name then the node is allowed to
+ continue possession. Otherwise it is assumed that the node has
+ released the name.
+
+ A name challenge may be issued by an NBNS or by a P or M node. A
+ challenge may be directed towards any end-node type: B, P, or M.
+
+15.1.3.4. GROUP NAME FADE-OUT
+
+ 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, an
+
+
+
+NetBIOS Working Group [Page 29]
+
+RFC 1001 March 1987
+
+
+ optimistic heuristic has been adopted. It is assumed that there will
+ always be some node which will defend a group name. Consequently, it
+ is recommended that the NBNS will immediately reject a claim request
+ for a unique name when there already exists a group with the same
+ name. The NBNS will never return an IP address (in response to a
+ NAME REGISTRATION REQUEST) when a group name exists.
+
+ An NBNS will consider a group to have faded out of existence when the
+ last remaining member fails to send a timely refresh message or
+ explicitly releases the name.
+
+15.1.3.5. NAME CONFLICT
+
+ Name conflict exists when a unique name has been claimed by more than
+ one node on a NetBIOS network. B, M, and NBNS nodes may detect a
+ name conflict. The detection mechanism used by B and M nodes is
+ active only during name discovery. The NBNS may detect conflict at
+ any time it verifies the consistency of its name database.
+
+ B and M nodes detect conflict by examining the responses received in
+ answer to a broadcast name query request. The first response is
+ taken as authoritative. Any subsequent, inconsistent responses
+ represent conflicts.
+
+ Subsequent responses are inconsistent with the authoritative response
+ when:
+
+ The subsequent response has the same transaction ID as the
+ NAME QUERY REQUEST.
+ AND
+ The subsequent response is not a duplicate of the
+ authoritative response.
+ AND EITHER:
+ The group/unique characteristic of the authoritative
+ response is "unique".
+ OR
+ The group/unique characteristic of the subsequent
+ response is "unique".
+
+ The period in which B and M nodes examine responses is limited by a
+ conflict timer, CONFLICT_TIMER. The accuracy or duration of this
+ timer is not crucial: the NetBIOS system will continue to operate
+ even with persistent name conflicts.
+
+ Conflict conditions are signaled by sending a NAME CONFLICT DEMAND to
+ the node owning the offending name. Nothing is sent to the node
+ which originated the authoritative response.
+
+ Any end-node that receives NAME CONFLICT DEMAND is required to update
+ its "local name table" to reflect that the name is in conflict. (The
+ "local name table" on each node contains names that have been
+
+
+
+NetBIOS Working Group [Page 30]
+
+RFC 1001 March 1987
+
+
+ successfully registered by that node.)
+
+ Notice that only those nodes that receive the name conflict message
+ place a conflict mark next to a name.
+
+ Logically, a marked name does not exist on that node. This means
+ that the node should not defend the name (for name claim purposes),
+ should not respond to a name discovery requests for that name, nor
+ should the node send name refresh messages for that name.
+ Furthermore, it can no longer be used by that node for any session
+ establishment or sending or receiving datagrams. Existing sessions
+ 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 error
+ code of "NAME CONFLICT".
+
+15.1.4. ADAPTER STATUS
+
+ An end-node or the NBNS may ask any other end-node for a collection
+ of information about the NetBIOS status of that node. This status
+ consists of, among other things, a list of the names which the node
+ believes it owns. The returned status is filtered to contain only
+ those names which have the same NetBIOS scope identifier as the
+ requestor's name.
+
+ When requesting node status, the requestor identifies the target node
+ by NetBIOS name A name query transaction may be necessary to acquire
+ the IP address for the name. Locally cached name information may be
+ used in lieu of a query transaction. The requesting node sends a
+ NODE STATUS REQUEST. In response, the receiving node sends a NODE
+ STATUS RESPONSE containing its local name table and various
+ statistics.
+
+ The amount of status which may be returned is limited by the size of
+ a UDP packet. However, this is sufficient for the typical NODE
+ STATUS RESPONSE packet.
+
+15.1.5. END-NODE NBNS INTERACTION
+
+ There are certain characteristics of end-node to NBNS interactions
+ which are in common and are independent of any particular transaction
+ type.
+
+15.1.5.1. UDP, TCP, AND TRUNCATION
+
+ For all transactions between an end-node and an NBNS, either UDP or
+ TCP may be used as a transport. If the NBNS receives a UDP based
+ request, it will respond using UDP. If the amount of information
+ exceeds what fits into a UDP packet, the response will contain a
+ "truncation flag". In this situation, the end- node may open a TCP
+
+
+
+NetBIOS Working Group [Page 31]
+
+RFC 1001 March 1987
+
+
+ connection to the NBNS, repeat the request, and receive a complete,
+ untruncated response.
+
+15.1.5.2. NBNS WACK
+
+ While a name service request is in progress, the NBNS may issue a
+ WAIT FOR ACKNOWLEDGEMENT RESPONSE (WACK) to assure the client end-
+ node that the NBNS is still operational and is working on the
+ request.
+
+15.1.5.3. NBNS REDIRECTION
+
+ The NBNS, because it follows Domain Name system styles of
+ interaction, is permitted to redirect a client to another NBNS.
+
+15.1.6. SECURED VERSUS NON-SECURED NBNS
+
+ An NBNS may be implemented in either of two general ways: The NBNS
+ may monitor, and participate in, name activity to ensure consistency.
+ This would be a "secured" style NBNS. Alternatively, an NBNS may be
+ implemented to be essentially a "bulletin board" on which name
+ information is posted and responsibility for consistency is delegated
+ to the end-nodes. This would be a "non-secured" style NBNS.
+
+15.1.7. CONSISTENCY OF THE NBNS DATA BASE
+
+ Even in a properly running NetBIOS scope the NBNS and its community
+ of end-nodes may occasionally lose synchronization with respect to
+ the true state of name registrations.
+
+ This may occur should the NBNS fail and lose all or part of its
+ database.
+
+ More commonly, a P or M node may be turned-off (thus forgetting the
+ names it has registered) and then be subsequently turned back on.
+
+ Finally, errors may occur or an implementation may be incorrect.
+
+ Various approaches have been incorporated into the NetBIOS-over- TCP
+ protocols to minimize the impact of these problems.
+
+ 1. The NBNS (or any other node) may "challenge" (using a NAME
+ QUERY REQUEST) an end-node to verify that it actually owns a
+ name.
+
+ Such a challenge may occur at any time. Every end-node must
+ be prepared to make a timely response.
+
+ Failure to respond causes the NBNS to consider that the
+ end-node has released the name in question.
+
+
+
+
+NetBIOS Working Group [Page 32]
+
+RFC 1001 March 1987
+
+
+ (If UDP is being used as the underlying transport, the
+ challenge, like all other requests, must be retransmitted
+ some number of times in the absence of a response.)
+
+ 2. The NBNS (or any other node) may request (using the NODE
+ STATUS REQUEST) that an end-node deliver its entire name
+ table.
+
+ This may occur at any time. Every end-node must be prepared
+ to make a timely response.
+
+ Failure to respond permits (but does not require) the NBNS
+ to consider that the end-node has failed and released all
+ names to which it had claims. (Like the challenge, on a UDP
+ transport, the request must be retransmitted in the absence
+ of a response.)
+
+ 3. The NBNS may revoke a P or M node's use of a name by sending
+ either a NAME CONFLICT DEMAND or a NAME RELEASE REQUEST to
+ the node.
+
+ The receiving end-node may continue existing sessions which
+ use that name, but must otherwise cease using that name. If
+ the NBNS placed the name in conflict, the name may be re-
+ acquired only by deletion and subsequent reclamation. If
+ the NBNS requested that the name be released, the node may
+ attempt to re-acquire the name without first performing a
+ name release transaction.
+
+ 4. The NBNS may impose a "time-to-live" on each name it
+ registers. The registering node is made aware of this time
+ value during the name registration procedure.
+
+ Simple or reliable NBNS's may impose an infinite time-to-
+ live.
+
+ 5. If an end-node holds any names that have finite time-to-
+ live values, then that node must periodically send a status
+ report to the NBNS. Each name is reported using the NAME
+ REFRESH REQUEST packet.
+
+ These status reports restart the timers of both the NBNS and
+ the reporting node. However, the only timers which are
+ restarted are those associated with the name found in the
+ status report. Timers on other names are not affected.
+
+ The NBNS may consider that a node has released any name
+ which has not been refreshed within some multiple of name's
+ time-to-live.
+
+ A well-behaved NBNS, would, however, issue a challenge to-,
+
+
+
+NetBIOS Working Group [Page 33]
+
+RFC 1001 March 1987
+
+
+ or request a list of names from-, the non-reporting end-
+ node before deleting its name(s). The absence of a
+ response, or of the name in a response, will confirm the
+ NBNS decision to delete a name.
+
+ 6. The absence of reports may cause the NBNS to infer that the
+ end-node has failed. Similarly, receipt of information
+ widely divergent from what the NBNS believes about the node,
+ may cause the NBNS to consider that the end-node has been
+ restarted.
+
+ The NBNS may analyze the situation through challenges or
+ requests for a list of names.
+
+ 7. A very cautious NBNS is free to poll nodes (by sending NAME
+ QUERY REQUEST or NODE STATUS REQUEST packets) to verify that
+ their name status is the same as that registered in the
+ NBNS.
+
+ NOTE: Such polling activity, if used at all by an
+ implementation, should be kept at a very low level or
+ enabled only during periods when the NBNS has some reason to
+ suspect that its information base is inaccurate.
+
+ 8. P and M nodes can detect incorrect name information at
+ session establishment.
+
+ If incorrect information is found, NBNS is informed via a
+ NAME RELEASE REQUEST originated by the end-node which
+ detects the error.
+
+15.1.8. NAME CACHING
+
+ An end-node may keep a local cache of NetBIOS name-to-IP address
+ translation entries.
+
+ All cache entries should be flushed on a periodic basis.
+
+ In addition, a node ought to flush any cache information associated
+ with an IP address if the node receives any information indicating
+ that there may be any possibility of trouble with the node at that IP
+ address. For example, if a NAME CONFLICT DEMAND is sent to a node,
+ all cached information about that node should be cleared within the
+ sending node.
+
+15.2. NAME REGISTRATION TRANSACTIONS
+
+15.2.1. NAME REGISTRATION BY B NODES
+
+ A name claim transaction initiated by a B node is broadcast
+ throughout the broadcast area. The NAME REGISTRATION REQUEST will be
+
+
+
+NetBIOS Working Group [Page 34]
+
+RFC 1001 March 1987
+
+
+ heard by all B and M nodes in the area. Each node examines the claim
+ to see whether it it is consistent with the names it owns. If an
+ inconsistency exists, a NEGATIVE NAME REGISTRATION RESPONSE is
+ unicast to the requestor. The requesting node obtains ownership of
+ the name (or membership in the group) if, and only if, no NEGATIVE
+ NAME REGISTRATION RESPONSEs are received within the name claim
+ timeout, CONFLICT_TIMER. (See "Defined Constants and Variables" in
+ the Detailed Specification for the value of this timer.)
+
+ A B node proclaims its new ownership by broadcasting a NAME OVERWRITE
+ DEMAND.
+
+ B-NODE REGISTRATION PROCESS
+ <-----NAME NOT ON NETWORK------> <----NAME ALREADY EXISTS---->
+
+ REQ. NODE NODE REQ.NODE
+ HOLDING
+ NAME
+
+ (BROADCAST) REGISTER (BROADCAST) REGISTER
+ -------------------> <-------------------
+
+ REGISTER REGISTER
+ -------------------> <-------------------
+
+ REGISTER NEGATIVE RESPONSE
+ -------------------> ------------------------------>
+
+ OVERWRITE
+ -------------------> (NODE DOES NOT HAVE THE NAME)
+
+ (NODE HAS THE NAME)
+
+ The NAME REGISTRATION REQUEST, like any request, must be repeated if
+ no response is received within BCAST_REQ_RETRY_TIMEOUT. Transmission
+ of the request is attempted BCAST_REQ_RETRY_COUNT times.
+
+15.2.2. NAME REGISTRATION BY P NODES
+
+ A name registration may proceed in various ways depending whether
+ the name being registered is new to the NBNS. If the name is known
+ to the NBNS, then challenges may be sent to the prior holder(s).
+
+15.2.2.1. NEW NAME, OR NEW GROUP MEMBER
+
+ The diagram, below, shows the sequence of events when an end-node
+ registers a name which is new to the NBNS. (The diagram omits WACKs,
+ NBNS redirections, and retransmission of requests.)
+
+ This same interaction will occur if the name being registered is a
+ group name and the group already exists. The NBNS will add the
+
+
+
+NetBIOS Working Group [Page 35]
+
+RFC 1001 March 1987
+
+
+ registrant to the set of group members.
+
+ P-NODE REGISTRATION PROCESS
+ (server has no previous information about the name)
+
+ P-NODE NBNS
+ REGISTER
+ --------------------------------->
+
+ POSITIVE RESPONSE
+ <---------------------------------
+
+ The interaction is rather simple: the end-node sends a NAME
+ REGISTRATION REQUEST, the NBNS responds with a POSITIVE NAME
+ REGISTRATION RESPONSE.
+
+15.2.2.2. EXISTING NAME AND OWNER IS STILL ACTIVE
+
+ The following diagram shows interactions when an attempt is made to
+ register a unique name, the NBNS is aware of an existing owner, and
+ that existing owner is still active.
+
+ There are two sides to the diagram. The left side shows how a non-
+ secured NBNS would handle the matter. Secured NBNS activity is shown
+ on the right.
+
+ P-NODE REGISTRATION PROCESS
+ (server HAS a previous owner that IS active)
+
+
+ <------NON-SECURED STYLE-------> <---------SECURED STYLE------->
+
+ REQ. NODE NBNS NODE NBNS REQ.NODE
+ HOLDING
+ NAME
+
+ REGISTER REGISTER
+ -------------------> <-------------------
+ QUERY
+ END-NODE CHALLENGE <------------
+ <------------------- QUERY
+ <------------
+ QUERY
+ ----------------------------->
+ POSITIVE RESP
+ QUERY ------------>
+ -----------------------------> NEGATIVE RESPONSE
+ ----------------->
+
+ POSITIVE RESPONSE
+ <----------------------------
+
+
+
+NetBIOS Working Group [Page 36]
+
+RFC 1001 March 1987
+
+
+ A non-secured NBNS will answer the NAME REGISTRATION REQUEST with a
+ END-NODE CHALLENGE REGISTRATION RESPONSE. This response asks the
+ end-node to issue a challenge transaction against the node indicated
+ in the response. In this case, the prior node will defend against
+ the challenge and the registering end-node will simply drop the
+ registration attempt without further interaction with the NBNS.
+
+ A secured NBNS will refrain from answering the NAME REGISTRATION
+ REQUEST until the NBNS has itself challenged the prior holder(s) of
+ the name. In this case, the NBNS finds that that the name is still
+ being defended and consequently returns a NEGATIVE NAME REGISTRATION
+ RESPONSE to the registrant.
+
+ Due to the potential time for the secured NBNS to make the
+ challenge(s), it is likely that a WACK will be sent by the NBNS to
+ the registrant.
+
+ Although not shown in the diagram, a non-secured NBNS will send a
+ NEGATIVE NAME REGISTRATION RESPONSE to a request to register a unique
+ name when there already exists a group of the same name. A secured
+ NBNS may elect to poll (or challenge) the group members to determine
+ whether any active members remain. This may impose a heavy load on
+ the network. It is recommended that group names be allowed to fade-
+ out through the name refresh mechanism.
+
+15.2.2.3. EXISTING NAME AND OWNER IS INACTIVE
+
+ The following diagram shows interactions when an attempt is made to
+ register a unique name, the NBNS is aware of an existing owner, and
+ that existing owner is no longer active.
+
+ A non-secured NBNS will answer the NAME REGISTRATION REQUEST with a
+ END-NODE CHALLENGE REGISTRATION RESPONSE. This response asks the
+ end-node to issue a challenge transaction against the node indicated
+ in the response. In this case, the prior node will not defend
+ against the challenge. The registrant will inform the NBNS through a
+ NAME OVERWRITE REQUEST. The NBNS will replace the prior name
+ information in its database with the information in the overwrite
+ request.
+
+ A secured NBNS will refrain from answering the NAME REGISTRATION
+ REQUEST until the NBNS has itself challenged the prior holder(s) of
+ the name. In this case, the NBNS finds that that the name is not
+ being defended and consequently returns a POSITIVE NAME REGISTRATION
+ RESPONSE to the registrant.
+
+
+
+
+
+
+
+
+
+NetBIOS Working Group [Page 37]
+
+RFC 1001 March 1987
+
+
+ P-NODE REGISTRATION PROCESS
+ (server HAS a previous owner that is NOT active)
+
+
+ <------NON-SECURED STYLE-----> <----------SECURED STYLE-------->
+
+ REQ. NODE NBNS NODE NBNS REQ.NODE
+ HOLDING
+ NAME
+
+ REGISTER REGISTER
+ -------------------> <-------------------
+ QUERY
+ END-NODE CHALLENGE <------------
+ <------------------- QUERY
+ <------------
+ NAME QUERY REQUEST POSITIVE RESPONSE
+ ----------------------------> ------------------>
+ QUERY
+ ---------------------------->
+
+ OVERWRITE
+ ------------------->
+
+ POSITIVE RESPONSE
+ <------------------
+
+ Due to the potential time for the secured NBNS to make the
+ challenge(s), it is likely that a WACK will be sent by the NBNS to
+ the registrant.
+
+ A secured NBNS will immediately send a NEGATIVE NAME REGISTRATION
+ RESPONSE in answer to any NAME OVERWRITE REQUESTS it may receive.
+
+15.2.3. NAME REGISTRATION BY M NODES
+
+ An M node begin a name claim operation as if the node were a B node:
+ it broadcasts a NAME REGISTRATION REQUEST and listens for NEGATIVE
+ NAME REGISTRATION RESPONSEs. Any NEGATIVE NAME REGISTRATION RESPONSE
+ prevents the M node from obtaining the name and terminates the claim
+ operation.
+
+ If, however, the M node does not receive any NEGATIVE NAME
+ REGISTRATION RESPONSE, the M node must continue the claim procedure
+ as if the M node were a P node.
+
+ Only if both name claims were successful does the M node acquire the
+ name.
+
+ The following diagram illustrates M node name registration:
+
+
+
+
+NetBIOS Working Group [Page 38]
+
+RFC 1001 March 1987
+
+
+ M-NODE REGISTRATION PROCESS
+
+ <---NAME NOT IN BROADCAST AREA--> <--NAME IS IN BROADCAST AREA-->
+
+ REQ. NODE NODE REQ.NODE
+ HOLDING
+ NAME
+
+ (BROADCAST) REGISTER (BROADCAST) REGISTER
+ -------------------> <-------------------
+
+ REGISTER REGISTER
+ -------------------> <-------------------
+
+ REGISTER NEGATIVE RESPONSE
+ -------------------> ------------------------------->
+
+
+ ! (NODE DOES NOT HAVE THE NAME)
+ INITIATE !
+ A P-NODE !
+ REGISTRATION !
+ V
+
+15.3. NAME QUERY TRANSACTIONS
+
+ Name query transactions are initiated by end-nodes to obtain the IP
+ address(es) and other attributes associated with a NetBIOS name.
+
+15.3.1. QUERY BY B NODES
+
+ The following diagram shows how B nodes go about discovering who owns
+ a name.
+
+ The left half of the diagram illustrates what happens if there are no
+ holders of the name. In that case no responses are received in
+ answer to the broadcast NAME QUERY REQUEST(s).
+
+ The right half shows a POSITIVE NAME QUERY RESPONSE unicast by a name
+ holder in answer to the broadcast request. A name holder will make
+ this response to every NAME QUERY REQUEST that it hears. And each
+ holder acts this way. Thus, the node sending the request may receive
+ many responses, some duplicates, and from many nodes.
+
+
+
+
+
+
+
+
+
+
+
+NetBIOS Working Group [Page 39]
+
+RFC 1001 March 1987
+
+
+ B-NODE DISCOVERY PROCESS
+
+
+ <------NAME NOT ON NETWORK------> <---NAME PRESENT ON NETWORK-->
+
+ REQ. NODE NODE REQ.NODE
+ HOLDING
+ NAME
+
+ (BROADCAST) QUERY (BROADCAST) QUERY
+ ----------------------> <---------------------
+
+ NAME QUERY REQUEST NAME QUERY REQUEST
+ ----------------------> <---------------------
+
+ QUERY POSITIVE RESPONSE
+ ----------------------> ------------------------------>
+
+ Name query is generally, but not necessarily, a prelude to NetBIOS
+ session establishment or NetBIOS datagram transmission. However,
+ name query may be used for other purposes.
+
+ A B node may elect to build a group membership list for subsequent
+ use (e.g. for session establishment) by collecting and saving the
+ responses.
+
+15.3.2. QUERY BY P NODES
+
+ An NBNS answers queries from a P node with a list of IP address and
+ other information for each owner of the name. If there are multiple
+ owners (i.e. if the name is a group name), the NBNS loads as many
+ answers into the response as will fit into a UDP packet. A
+ truncation flag indicates whether any additional owner information
+ remains. All the information may be obtained by repeating the query
+ over a TCP connection.
+
+ The NBNS is not required to impose any order on its answer list.
+
+ The following diagram shows what happens if the NBNS has no
+ information about the name:
+
+ P-NODE DISCOVERY PROCESS
+ (server has no information about the name)
+
+ P-NODE NBNS
+ NAME QUERY REQUEST
+ --------------------------------->
+
+ NEGATIVE RESPONSE
+ <---------------------------------
+
+
+
+
+NetBIOS Working Group [Page 40]
+
+RFC 1001 March 1987
+
+
+ The next diagram illustrates interaction between the end-node and the
+ NBNS when the NBNS does have information about the name. This
+ diagram shows, in addition, the retransmission of the request by the
+ end-node in the absence of a timely response. Also shown are WACKs
+ (or temporary, intermediate responses) sent by the NBNS to the end-
+ node:
+
+ P-NODE QUERY PROCESS
+ (server HAS information about the name)
+
+ P-NODE NBNS
+ NAME QUERY REQUEST
+ /---------------------------------------->
+ /
+ ! (OPTIONAL) WACK
+ ! <- - - - - - - - - - - - - - - - - - - -
+ ! !
+ !timer !
+ ! ! (optional timer restart)
+ ! !
+ \ V QUERY
+ \--------------------------------------->
+ .
+ .
+ .
+ QUERY
+ /---------------------------------------->
+ /
+ ! (OPTIONAL) WACK
+ ! <- - - - - - - - - - - - - - - - - - - -
+ ! !
+ !timer !
+ ! ! (optional timer restart)
+ ! !
+ \ V QUERY
+ \--------------------------------------->
+ .
+ .
+
+ POSITIVE RESPONSE
+ <-----------------------------------------
+
+
+ The following diagram illustrates NBNS redirection. Upon receipt of
+ a NAME QUERY REQUEST, the NBNS redirects the client to another NBNS.
+ The client repeats the request to the new NBNS and obtains a
+ response. The diagram shows that response as a POSITIVE NAME QUERY
+ RESPONSE. However any legal NBNS response may occur in actual
+ operation.
+
+
+
+
+
+NetBIOS Working Group [Page 41]
+
+RFC 1001 March 1987
+
+
+ NBNS REDIRECTION
+
+ P-NODE NBNS
+ NAME QUERY REQUEST
+ --------------------------------->
+
+ REDIRECT NAME QUERY RESPONSE
+ <---------------------------------
+
+ (START FROM THE
+ VERY BEGINNING
+ USING THE ADDRESS
+ OF THE NEWLY
+ SUPPLIED NBNS.)
+ NEW
+ P-NODE NBNS
+ NAME QUERY REQUEST
+ --------------------------------->
+
+ POSITIVE NAME QUERY RESPONSE
+ <---------------------------------
+
+ The next diagram shows how a P or M node tells the NBNS that the NBNS
+ has provided incorrect information. This procedure may begin after a
+ DATAGRAM ERROR packet has been received or a session set-up attempt
+ has discovered that the NetBIOS name does not exist at the
+ destination, the IP address of which was obtained from the NBNS
+ during a prior name query transaction. The NBNS, in this case a
+ secure NBNS, issues queries to verify whether the information is, in
+ fact, incorrect. The NBNS closes the transaction by sending either a
+ POSITIVE or NEGATIVE NAME RELEASE RESPONSE, depending on the results
+ of the verification.
+
+ CORRECTING NBNS INFORMATION BASE
+
+ P-NODE NBNS
+ NAME RELEASE REQUEST
+ --------------------------------->
+ QUERY
+ ---------------->
+
+ QUERY
+ ---------------->
+
+ (NAME TAKEN OFF THE DATABASE
+ IF NBNS FINDS IT TO BE
+ INCORRECT)
+
+ POSITIVE/NEGATIVE RESPONSE
+ <---------------------------------
+
+
+
+
+NetBIOS Working Group [Page 42]
+
+RFC 1001 March 1987
+
+
+15.3.3. QUERY BY M NODES
+
+ M node name query follows the B node pattern. In the absence of
+ adequate results, the M node then continues by performing a P node
+ type query. This is shown in the following diagram:
+
+ M-NODE DISCOVERY PROCESS
+
+
+ <---NAME NOT ON BROADCAST AREA--> <--NAME IS ON BROADCAST AREA->
+
+ REQ. NODE NODE REQ.NODE
+ HOLDING
+ NAME
+
+ (BROADCAST) QUERY (BROADCAST) QUERY
+ ---------------------> <----------------------
+
+ NAME QUERY REQUEST NAME QUERY REQUEST
+ ---------------------> <----------------------
+
+ QUERY POSITIVE RESPONSE
+ ---------------------> ------------------------------->
+
+ !
+ INITIATE !
+ A P-NODE !
+ DISCOVERY !
+ PROCESS !
+ V
+
+
+
+15.3.4. ACQUIRE GROUP MEMBERSHIP LIST
+
+ The entire membership of a group may be acquired by sending a NAME
+ QUERY REQUEST to the NBNS. The NBNS will respond with a POSITIVE
+ NAME QUERY RESPONSE or a NEGATIVE NAME QUERY RESPONSE. A negative
+ response completes the procedure and indicates that there are no
+ members in the group.
+
+ If the positive response has the truncation bit clear, then the
+ response contains the entire list of group members. If the
+ truncation bit is set, then this entire procedure must be repeated,
+ but using TCP as a foundation rather than UDP.
+
+
+
+
+
+
+
+
+
+NetBIOS Working Group [Page 43]
+
+RFC 1001 March 1987
+
+
+15.4. NAME RELEASE TRANSACTIONS
+
+15.4.1. RELEASE BY B NODES
+
+ A NAME RELEASE DEMAND contains the following information:
+
+ - NetBIOS name
+ - The scope of the NetBIOS name
+ - Name type: unique or group
+ - IP address of the releasing node
+ - Transaction ID
+
+ REQUESTING OTHER
+ B-NODE B-NODES
+ NAME RELEASE DEMAND
+ ---------------------------------->
+
+15.4.2. RELEASE BY P NODES
+
+ A NAME RELEASE REQUEST contains the following information:
+
+ - NetBIOS name
+ - The scope of the NetBIOS name
+ - Name type: unique or group
+ - IP address of the releasing node
+ - Transaction ID
+
+
+ A NAME RELEASE RESPONSE contains the following information:
+
+ - NetBIOS name
+ - The scope of the NetBIOS name
+ - Name type: unique or group
+ - IP address of the releasing node
+ - Transaction ID
+ - Result:
+ - Yes: name was released
+ - No: name was not released, a reason code is provided
+
+ REQUESTING
+ P-NODE NBNS
+ NAME RELEASE REQUEST
+ ---------------------------------->
+
+ NAME RELEASE RESPONSE
+ <---------------------------------
+
+15.4.3. RELEASE BY M NODES
+
+ The name release procedure of the M node is a combination of the P
+ and B node name release procedures. The M node first performs the P
+
+
+
+NetBIOS Working Group [Page 44]
+
+RFC 1001 March 1987
+
+
+ release procedure. If the P procedure fails then the release
+ procedure does not continue, it fails. If and only if the P
+ procedure succeeds then the M node broadcasts the NAME RELEASE DEMAND
+ to the broadcast area, the B procedure.
+
+ NOTE: An M node typically performs a B-style operation and then a
+ P-style operation. In this case, however, the P-style
+ operation comes first.
+
+ The following diagram illustrates the M node name release procedure:
+
+ <-----P procedure fails-------> <-------P procedure succeeds--->
+
+ REQUESTING NBNS REQUESTING NBNS
+ M-NODE M-NODE
+
+ NAME RELEASE REQUEST NAME RELEASE REQUEST
+ --------------------------> ------------------------>
+
+ NEGATIVE RELEASE RESPONSE POSITIVE RELEASE RESPONSE
+ <-------------------------- <-------------------------
+
+ OTHER
+ M-NODES
+
+ NAME RELEASE DEMAND
+ ------------------------>
+
+15.5. NAME MAINTENANCE TRANSACTIONS
+
+15.5.1. NAME REFRESH
+
+ Name refresh transactions are used to handle the following
+ situations:
+
+ a) An NBNS node needs to detect if a P or M node has "silently"
+ gone down, so that names held by that node can be purged
+ from the data base.
+
+
+ b) If the NBNS goes down, it needs to be able to reconstruct
+ the data base when it comes back up.
+
+
+ c) If the network should be partitioned, the NBNS needs to be
+ able to able to update its data base when the network
+ reconnects.
+
+ Each P or M node is responsible for sending periodic NAME REFRESH
+ REQUESTs for each name that it has registered. Each refresh packet
+ contains a single name that has been successfully registered by that
+
+
+
+NetBIOS Working Group [Page 45]
+
+RFC 1001 March 1987
+
+
+ node. The interval between such packets is negotiated between the
+ end node and the NBNS server at the time that the name is initially
+ claimed. At name claim time, an end node will suggest a refresh
+ timeout value. The NBNS node can modify this value in the reply
+ packet. A NBNS node can also choose to tell the end node to not send
+ any refresh packet by using the "infinite" timeout value in the
+ response packet. The timeout value returned by the NBNS is the
+ actual refresh timeout that the end node must use.
+
+ When a node sends a NAME REFRESH REQUEST, it must be prepared to
+ receive a negative response. This would happen, for example, if the
+ the NBNS discovers that the the name had already been assigned to
+ some other node. If such a response is received, the end node should
+ mark the name as being in conflict. Such an entry should be treated
+ in the same way as if name conflict had been detected against the
+ name. The following diagram illustrates name refresh:
+
+ <-----Successful Refresh-----> <-----Unsuccessful Refresh---->
+
+ REFRESHING NBNS REFRESHING NBNS
+ NODE NODE
+
+ NAME REFRESH REQUEST NAME REFRESH REQUEST
+ ------------------------> ----------------------->
+
+ POSITIVE RESPONSE NEGATIVE RESPONSE
+ <------------------------ <-----------------------
+ !
+ !
+ V
+ MARK NAME IN
+ CONFLICT
+
+15.5.2. NAME CHALLENGE
+
+ Name challenge is done by sending a NAME QUERY REQUEST to an end node
+ of any type. If a POSITIVE NAME QUERY RESPONSE is returned, then
+ that node still owns the name. If a NEGATIVE NAME QUERY RESPONSE is
+ received or if no response is received, it can be assumed that the
+ end node no longer owns the name.
+
+ Name challenge can be performed either by the NBNS node, or by an end
+ node. When an end-node sends a name claim packet, the NBNS node may
+ do the challenge operation. The NBNS node can choose, however, to
+ require the end node do the challenge. In that case, the NBNS will
+ send an END-NODE CHALLENGE RESPONSE packet to the end node, which
+ should then proceed to challenge the putative owner.
+
+ Note that the name challenge procedure sends a normal NAME QUERY
+ REQUEST packet to the end node. It does not require a special
+ packet. The only new packet introduced is the END-NODE CHALLENGE
+
+
+
+NetBIOS Working Group [Page 46]
+
+RFC 1001 March 1987
+
+
+ RESPONSE which is sent by an NBNS node when the NBNS wants the end-
+ node to perform the challenge operation.
+
+15.5.3. CLEAR NAME CONFLICT
+
+ It is possible during a refresh request from a M or P node for a NBNS
+ to detects a name in conflict. The response to the NAME REFRESH
+ REQUEST must be a NEGATIVE NAME REGISTRATION RESPONSE. Optionally,
+ in addition, the NBNS may send a NAME CONFLICT DEMAND or a NAME
+ RELEASE REQUEST to the refreshing node. The NAME CONFLICT DEMAND
+ forces the node to place the name in the conflict state. The node
+ will eventually inform it's user of the conflict. The NAME RELEASE
+ REQUEST will force the node to flush the name from its local name
+ table completely. This forces the node to flush the name in
+ conflict. This does not cause termination of existing sessions using
+ this name.
+
+ The following diagram shows an NBNS detecting and correcting a
+ conflict:
+
+ REFRESHING NODE NBNS
+
+ NAME REFRESH REQUEST
+ ----------------------------------------->
+
+ NEGATIVE NAME REGISTRATION RESPONSE
+ <-----------------------------------------
+
+ NAME CONFLICT DEMAND
+ <-----------------------------------------
+
+ OR
+
+ NAME RELEASE REQUEST
+ <-----------------------------------------
+
+ POSITIVE/NEGATIVE RELEASE REQUEST
+ ----------------------------------------->
+
+15.6. ADAPTER STATUS TRANSACTIONS
+
+ Adapter status is obtained from a node as follows:
+
+ 1. Perform a name discovery operation to obtain the IP
+ addresses of a set of end-nodes.
+
+ 2. Repeat until all end-nodes from the set have been used:
+
+ a. Select one end-node from the set.
+
+ b. Send a NODE STATUS REQUEST to that end-node using UDP.
+
+
+
+NetBIOS Working Group [Page 47]
+
+RFC 1001 March 1987
+
+
+ c. Await a NODE STATUS RESPONSE. (If a timely response is
+ not forthcoming, repeat step "b" UCAST_REQ_RETRY_COUNT
+ times. After the last retry, go to step "a".)
+
+ d. If the truncation bit is not set in the response, the
+ response contains the entire node status. Return the
+ status to the user and terminate this procedure.
+
+ e. If the truncation bit is set in the response, then not
+ all status was returned because it would not fit into
+ the response packet. The responder will set the
+ truncation bit if the IP datagram length would exceed
+ MAX_DATAGRAM_LENGTH. Return the status to the user and
+ terminate this procedure.
+
+
+3. Return error to user, no status obtained.
+
+ The repetition of step 2, above, through all nodes of the set, is
+ optional.
+
+ Following is an example transaction of a successful Adapter Status
+ operation:
+
+ REQUESTING NODE NAME OWNER
+
+ NAME QUERY REQUEST
+ ----------------------------------------->
+
+ POSITIVE NAME QUERY RESPONSE
+ <-----------------------------------------
+
+ NODE STATUS REQUEST
+ ----------------------------------------->
+
+ NODE STATUS RESPONSE
+ <-----------------------------------------
+
+16. NetBIOS SESSION SERVICE
+
+ The NetBIOS session service begins after one or more IP addresses
+ have been found for the target name. These addresses may have been
+ acquired using the NetBIOS name query transactions or by other means,
+ such as a local name table or cache.
+
+ NetBIOS session service transactions, packets, and protocols are
+ identical for all end-node types. They involve only directed
+ (point-to-point) communications.
+
+
+
+
+
+
+NetBIOS Working Group [Page 48]
+
+RFC 1001 March 1987
+
+
+16.1. OVERVIEW OF NetBIOS SESSION SERVICE
+
+ Session service has three phases:
+
+ Session establishment - it is during this phase that the IP
+ address and TCP port of the called name is determined, and a
+ TCP connection is established with the remote party.
+
+ Steady state - it is during this phase that NetBIOS data
+ messages are exchanged over the session. Keep-alive packets
+ may also be exchanged if the participating nodes are so
+ configured.
+
+ Session close - a session is closed whenever either a party (in
+ the session) closes the session or it is determined that one
+ of the parties has gone down.
+
+16.1.1. SESSION ESTABLISHMENT PHASE OVERVIEW
+
+ An end-node begins establishment of a session to another node by
+ somehow acquiring (perhaps using the name query transactions or a
+ local cache) the IP address of the node or nodes purported to own the
+ destination name.
+
+ Every end-node awaits incoming NetBIOS session requests by listening
+ for TCP calls to a well-known service port, SSN_SRVC_TCP_PORT. Each
+ incoming TCP connection represents the start of a separate NetBIOS
+ session initiation attempt. The NetBIOS session server, not the
+ ultimate application, accepts the incoming TCP connection(s).
+
+ Once the TCP connection is open, the calling node sends session
+ service request packet. This packet contains the following
+ information:
+
+ - Calling IP address (see note)
+ - Calling NetBIOS name
+ - Called IP address (see note)
+ - Called NetBIOS name
+
+ NOTE: The IP addresses are obtained from the TCP service
+ interface.
+
+ When the session service request packet arrives at the NetBIOS
+ server, one of the the following situations will exist:
+
+ - There exists a NetBIOS LISTEN compatible with the incoming
+ call and there are adequate resources to permit session
+ establishment to proceed.
+
+ - There exists a NetBIOS LISTEN compatible with the incoming
+ call, but there are inadequate resources to permit
+
+
+
+NetBIOS Working Group [Page 49]
+
+RFC 1001 March 1987
+
+
+ establishment of a session.
+
+ - The called name does, in fact, exist on the called node, but
+ there is no pending NetBIOS LISTEN compatible with the
+ incoming call.
+
+ - The called name does not exist on the called node.
+
+ In all but the first case, a rejection response is sent back over the
+ TCP connection to the caller. The TCP connection is then closed and
+ the session phase terminates. Any retry is the responsibility of the
+ caller. For retries in the case of a group name, the caller may use
+ the next member of the group rather than immediately retrying the
+ instant address. In the case of a unique name, the caller may
+ attempt an immediate retry using the same target IP address unless
+ the called name did not exist on the called node. In that one case,
+ the NetBIOS name should be re-resolved.
+
+ If a compatible LISTEN exists, and there are adequate resources, then
+ the session server may transform the existing TCP connection into the
+ NetBIOS data session. Alternatively, the session server may
+ redirect, or "retarget" the caller to another TCP port (and IP
+ address).
+
+ If the caller is redirected, the caller begins the session
+ establishment anew, but using the new IP address and TCP port given
+ in the retarget response. Again a TCP connection is created, and
+ again the calling and called node exchange credentials. The called
+ party may accept the call, reject the call, or make a further
+ redirection.
+
+ This mechanism is based on the presumption that, on hosts where it is
+ not possible to transfer open TCP connections between processes, the
+ host will have a central session server. Applications willing to
+ receive NetBIOS calls will obtain an ephemeral TCP port number, post
+ a TCP unspecified passive open on that port, and then pass that port
+ number and NetBIOS name information to the NetBIOS session server
+ using a NetBIOS LISTEN operation. When the call is placed, the
+ session server will "retarget" the caller to the application's TCP
+ socket. The caller will then place a new call, directly to the
+ application. The application has the responsibility to mimic the
+ session server at least to the extent of receiving the calling
+ credentials and then accepting or rejecting the call.
+
+16.1.1.1. RETRYING AFTER BEING RETARGETTED
+
+ A calling node may find that it can not establish a session with a
+ node to which it was directed by the retargetting procedure. Since
+ retargetting may be nested, there is an issue whether the caller
+ should begin a retry at the initial starting point or back-up to an
+ intermediate retargetting point. The caller may use any method. A
+
+
+
+NetBIOS Working Group [Page 50]
+
+RFC 1001 March 1987
+
+
+ discussion of two such methods is in Appendix B, "Retarget
+ Algorithms".
+
+16.1.1.2. SESSION ESTABLISHMENT TO A GROUP NAME
+
+ Session establishment with a group name requires special
+ consideration. When a NetBIOS CALL attempt is made to a group name,
+ name discovery will result in a list (possibly incomplete) of the
+ members of that group. The calling node selects one member from the
+ list and attempts to build a session. If that fails, the calling
+ node may select another member and make another attempt.
+
+ When the session service attempts to make a connection with one of
+ the members of the group, there is no guarantee that that member has
+ a LISTEN pending against that group name, that the called node even
+ owns, or even that the called node is operating.
+
+16.1.2. STEADY STATE PHASE OVERVIEW
+
+ NetBIOS data messages are exchanged in the steady state. NetBIOS
+ messages are sent by prepending the user data with a message header
+ and sending the header and the user data over the TCP connection.
+ The receiver removes the header and passes the data to the NetBIOS
+ user.
+
+ In order to detect failure of one of the nodes or of the intervening
+ network, "session keep alive" packets may be periodically sent in the
+ steady state.
+
+ Any failure of the underlying TCP connection, whether a reset, a
+ timeout, or other failure, implies failure of the NetBIOS session.
+
+16.1.3. SESSION TERMINATION PHASE OVERVIEW
+
+ A NetBIOS session is terminated normally when the user requests the
+ session to be closed or when the session service detects the remote
+ partner of the session has gracefully terminated the TCP connection.
+ A NetBIOS session is abnormally terminated when the session service
+ detects a loss of the connection. Connection loss can be detected
+ with the keep-alive function of the session service or TCP, or on the
+ failure of a SESSION MESSAGE send operation.
+
+ When a user requests to close a session, the service first attempts a
+ graceful in-band close of the TCP connection. If the connection does
+ not close within the SSN_CLOSE_TIMEOUT the TCP connection is aborted.
+ No matter how the TCP connection is terminated, the NetBIOS session
+ service always closes the NetBIOS session.
+
+ When the session service receives an indication from TCP that a
+ connection close request has been received, the TCP connection and
+ the NetBIOS session are immediately closed and the user is informed
+
+
+
+NetBIOS Working Group [Page 51]
+
+RFC 1001 March 1987
+
+
+ of the loss of the session. All data received up to the close
+ indication should be delivered, if possible, to the session's user.
+
+16.2. SESSION ESTABLISHMENT PHASE
+
+ All the following diagrams assume a name query operation was
+ successfully completed by the caller node for the listener's name.
+
+ This first diagram shows the sequence of network events used to
+ successfully establish a session without retargetting by the
+ listener. The TCP connection is first established with the well-
+ known NetBIOS session service TCP port, SSN_SRVC_TCP_PORT. The
+ caller then sends a SESSION REQUEST packet over the TCP connection
+ requesting a session with the listener. The SESSION REQUEST contains
+ the caller's name and the listener's name. The listener responds
+ with a POSITIVE SESSION RESPONSE informing the caller this TCP
+ connection is accepted as the connection for the data transfer phase
+ of the session.
+
+ CALLER LISTENER
+
+ TCP CONNECT
+ ====================================>
+ TCP ACCEPT
+ <===================================
+ SESSION REQUEST
+ ------------------------------------>
+ POSITIVE RESPONSE
+ <-----------------------------------
+
+ The second diagram shows the sequence of network events used to
+ successfully establish a session when the listener does retargetting.
+ The session establishment procedure is the same as with the first
+ diagram up to the listener's response to the SESSION REQUEST. The
+ listener, divided into two sections, the listen processor and the
+ actual listener, sends a SESSION RETARGET RESPONSE to the caller.
+ This response states the call is acceptable, but the data transfer
+ TCP connection must be at the new IP address and TCP port. The
+ caller then re-iterates the session establishment process anew with
+ the new IP address and TCP port after the initial TCP connection is
+ closed. The new listener then accepts this connection for the data
+ transfer phase with a POSITIVE SESSION RESPONSE.
+
+ CALLER LISTEN PROCESSOR LISTENER
+
+ TCP CONNECT
+ =============================>
+ TCP ACCEPT
+ <=============================
+ SESSION REQUEST
+ ----------------------------->
+
+
+
+NetBIOS Working Group [Page 52]
+
+RFC 1001 March 1987
+
+
+ SESSION RETARGET RESPONSE
+ <-----------------------------
+ TCP CLOSE
+ <=============================
+ TCP CLOSE
+ =============================>
+
+ TCP CONNECT
+ ====================================================>
+ TCP ACCEPT
+ <====================================================
+ SESSION REQUEST
+ ---------------------------------------------------->
+ POSITIVE RESPONSE
+ <----------------------------------------------------
+
+ The third diagram is the sequence of network events for a rejected
+ session request with the listener. This type of rejection could
+ occur with either a non-retargetting listener or a retargetting
+ listener. After the TCP connection is established at
+ SSN_SRVC_TCP_PORT, the caller sends the SESSION REQUEST over the TCP
+ connection. The listener does not have either a listen pending for
+ the listener's name or the pending NetBIOS listen is specific to
+ another caller's name. Consequently, the listener sends a NEGATIVE
+ SESSION RESPONSE and closes the TCP connection.
+
+ CALLER LISTENER
+
+ TCP CONNECT
+ ====================================>
+ TCP ACCEPT
+ <===================================
+ SESSION REQUEST
+ ------------------------------------>
+ NEGATIVE RESPONSE
+ <-----------------------------------
+ TCP CLOSE
+ <===================================
+ TCP CLOSE
+ ====================================>
+
+ The fourth diagram is the sequence of network events when session
+ establishment fails with a retargetting listener. After being
+ redirected, and after the initial TCP connection is closed the caller
+ tries to establish a TCP connection with the new IP address and TCP
+ port. The connection fails because either the port is unavailable or
+ the target node is not active. The port unavailable race condition
+ occurs if another caller has already acquired the TCP connection with
+ the listener. For additional implementation suggestions, see
+ Appendix B, "Retarget Algorithms".
+
+
+
+
+NetBIOS Working Group [Page 53]
+
+RFC 1001 March 1987
+
+
+ CALLER LISTEN PROCESSOR LISTENER
+
+ TCP CONNECT
+ =============================>
+ TCP ACCEPT
+ <=============================
+ SESSION REQUEST
+ ----------------------------->
+ REDIRECT RESPONSE
+ <-----------------------------
+ TCP CLOSE
+ <=============================
+ TCP CLOSE
+ =============================>
+
+ TCP CONNECT
+ ====================================================>
+
+ CONNECTION REFUSED OR TIMED OUT
+ <===================================================
+
+
+16.3. SESSION DATA TRANSFER PHASE
+
+16.3.1. DATA ENCAPSULATION
+
+ NetBIOS messages are exchanged in the steady state. Messages are
+ sent by prepending user data with message header and sending the
+ header and the user data over the TCP connection. The receiver
+ removes the header and delivers the NetBIOS data to the user.
+
+16.3.2. SESSION KEEP-ALIVES
+
+ In order to detect node failure or network partitioning, "session
+ keep alive" packets are periodically sent in the steady state. A
+ session keep alive packet is discarded by a peer node.
+
+ A session keep alive timer is maintained for each session. This
+ timer is reset whenever any data is sent to, or received from, the
+ session peer. When the timer expires, a NetBIOS session keep-alive
+ packet is sent on the TCP connection. Sending the keep-alive packet
+ forces data to flow on the TCP connection, thus indirectly causing
+ TCP to detect whether the connection is still active.
+
+ Since many TCP implementations provide a parallel TCP "keep- alive"
+ mechanism, the NetBIOS session keep-alive is made a configurable
+ option. It is recommended that the NetBIOS keep- alive mechanism be
+ used only in the absence of TCP keep-alive.
+
+ Note that unlike TCP keep alives, NetBIOS session keep alives do not
+ require a response from the NetBIOS peer -- the fact that it was
+
+
+
+NetBIOS Working Group [Page 54]
+
+RFC 1001 March 1987
+
+
+ possible to send the NetBIOS session keep alive is sufficient
+ indication that the peer, and the connection to it, are still active.
+
+ The only requirement for interoperability is that when a session keep
+ alive packet is received, it should be discarded.
+
+17. NETBIOS DATAGRAM SERVICE
+
+17.1. OVERVIEW OF NetBIOS DATAGRAM SERVICE
+
+ Every NetBIOS datagram has a named destination and source. To
+ transmit a NetBIOS datagram, the datagram service must perform a name
+ query operation to learn the IP address and the attributes of the
+ destination NetBIOS name. (This information may be cached to avoid
+ the overhead of name query on subsequent NetBIOS datagrams.)
+
+ NetBIOS datagrams are carried within UDP packets. If a NetBIOS
+ datagram is larger than a single UDP packet, it may be fragmented
+ into several UDP packets.
+
+ End-nodes may receive NetBIOS datagrams addressed to names not held
+ by the receiving node. Such datagrams should be discarded. If the
+ name is unique then a DATAGRAM ERROR packet is sent to the source of
+ that NetBIOS datagram.
+
+17.1.1. UNICAST, MULTICAST, AND BROADCAST
+
+ NetBIOS datagrams may be unicast, multicast, or broadcast. A NetBIOS
+ datagram addressed to a unique NetBIOS name is unicast. A NetBIOS
+ datatgram addressed to a group NetBIOS name, whether there are zero,
+ one, or more actual members, is multicast. A NetBIOS datagram sent
+ using the NetBIOS "Send Broadcast Datagram" primitive is broadcast.
+
+17.1.2. FRAGMENTATION OF NetBIOS DATAGRAMS
+
+ When the header and data of a NetBIOS datagram exceeds the maximum
+ amount of data allowed in a UDP packet, the NetBIOS datagram must be
+ fragmented before transmission and reassembled upon receipt.
+
+ A NetBIOS Datagram is composed of the following protocol elements:
+
+ - IP header of 20 bytes (minimum)
+ - UDP header of 8 bytes
+ - NetBIOS Datagram Header of 14 bytes
+ - The NetBIOS Datagram data.
+
+ The NetBIOS Datagram data section is composed of 3 parts:
+
+ - Source NetBIOS name (255 bytes maximum)
+ - Destination NetBIOS name (255 bytes maximum)
+ - The NetBIOS user's data (maximum of 512 bytes)
+
+
+
+NetBIOS Working Group [Page 55]
+
+RFC 1001 March 1987
+
+
+ The two name fields are in second level encoded format (see section
+ 14.)
+
+ A maximum size NetBIOS datagram is 1064 bytes. The minimal maximum
+ IP datagram size is 576 bytes. Consequently, a NetBIOS Datagram may
+ not fit into a single IP datagram. This makes it necessary to permit
+ the fragmentation of NetBIOS Datagrams.
+
+ On networks meeting or exceeding the minimum IP datagram length
+ requirement of 576 octets, at most two NetBIOS datagram fragments
+ will be generated. The protocols and packet formats accommodate
+ fragmentation into three or more parts.
+
+ When a NetBIOS datagram is fragmented, the IP, UDP and NetBIOS
+ Datagram headers are present in each fragment. The NetBIOS Datagram
+ data section is split among resulting UDP datagrams. The data
+ sections of NetBIOS datagram fragments do not overlap. The only
+ fields of the NetBIOS Datagram header that would vary are the FLAGS
+ and OFFSET fields.
+
+ The FIRST bit in the FLAGS field indicate whether the fragment is the
+ first in a sequence of fragments. The MORE bit in the FLAGS field
+ indicates whether other fragments follow.
+
+ The OFFSET field is the byte offset from the beginning of the NetBIOS
+ datagram data section to the first byte of the data section in a
+ fragment. It is 0 for the first fragment. For each subsequent
+ fragment, OFFSET is the sum of the bytes in the NetBIOS data sections
+ of all preceding fragments.
+
+ If the NetBIOS datagram was not fragmented:
+
+ - FIRST = TRUE
+ - MORE = FALSE
+ - OFFSET = 0
+
+ If the NetBIOS datagram was fragmented:
+
+ - First fragment:
+ - FIRST = TRUE
+ - MORE = TRUE
+ - OFFSET = 0
+
+ - Intermediate fragments:
+ - FIRST = FALSE
+ - MORE = TRUE
+ - OFFSET = sum(NetBIOS data in prior fragments)
+
+ - Last fragment:
+ - FIRST = FALSE
+ - MORE = FALSE
+
+
+
+NetBIOS Working Group [Page 56]
+
+RFC 1001 March 1987
+
+
+ - OFFSET = sum(NetBIOS data in prior fragments)
+
+ The relative position of intermediate fragments may be ascertained
+ from OFFSET.
+
+ An NBDD must remember the destination name of the first fragment in
+ order to relay the subsequent fragments of a single NetBIOS datagram.
+ The name information can be associated with the subsequent fragments
+ through the transaction ID, DGM_ID, and the SOURCE_IP, fields of the
+ packet. This information can be purged by the NBDD after the last
+ fragment has been processed or FRAGMENT_TO time has expired since the
+ first fragment was received.
+
+17.2. NetBIOS DATAGRAMS BY B NODES
+
+ For NetBIOS datagrams with a named destination (i.e. non- broadcast),
+ a B node performs a name discovery for the destination name before
+ sending the datagram. (Name discovery may be bypassed if information
+ from a previous discovery is held in a cache.) If the name type
+ returned by name discovery is UNIQUE, the datagram is unicast to the
+ sole owner of the name. If the name type is GROUP, the datagram is
+ broadcast to the entire broadcast area using the destination IP
+ address BROADCAST_ADDRESS.
+
+ A receiving node always filters datagrams based on the destination
+ name. If the destination name is not owned by the node or if no
+ RECEIVE DATAGRAM user operations are pending for the name, then the
+ datagram is discarded. For datagrams with a UNIQUE name destination,
+ if the name is not owned by the node then the receiving node sends a
+ DATAGRAM ERROR packet. The error packet originates from the
+ DGM_SRVC_UDP_PORT and is addressed to the SOURCE_IP and SOURCE_PORT
+ from the bad datagram. The receiving node quietly discards datagrams
+ with a GROUP name destination if the name is not owned by the node.
+
+ Since broadcast NetBIOS datagrams do not have a named destination,
+ the B node sends the DATAGRAM SERVICE packet(s) to the entire
+ broadcast area using the destination IP address BROADCAST_ADDRESS.
+ In order for the receiving nodes to distinguish this datagram as a
+ broadcast NetBIOS datagram, the NetBIOS name used as the destination
+ name is '*' (hexadecimal 2A) followed by 15 bytes of hexidecimal 00.
+ The NetBIOS scope identifier is appended to the name before it is
+ converted into second-level encoding. For example, if the scope
+ identifier is "NETBIOS.SCOPE" then the first-level encoded name would
+ be:
+
+ CKAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA.NETBIOS.SCOPE
+
+ According to [2], a user may not provide a NetBIOS name beginning
+ with "*".
+
+ For each node in the broadcast area that receives the NetBIOS
+
+
+
+NetBIOS Working Group [Page 57]
+
+RFC 1001 March 1987
+
+
+ broadcast datagram, if any RECEIVE BROADCAST DATAGRAM user operations
+ are pending then the data from the NetBIOS datagram is replicated and
+ delivered to each. If no such operations are pending then the node
+ silently discards the datagram.
+
+17.3. NetBIOS DATAGRAMS BY P AND M NODES
+
+ P and M nodes do not use IP broadcast to distribute NetBIOS
+ datagrams.
+
+ Like B nodes, P and M nodes must perform a name discovery or use
+ cached information to learn whether a destination name is a group or
+ a unique name.
+
+ Datagrams to unique names are unicast directly to the destination by
+ P and M nodes, exactly as they are by B nodes.
+
+ Datagrams to group names and NetBIOS broadcast datagrams are unicast
+ to the NBDD. The NBDD then relays the datagrams to each of the nodes
+ specified by the destination name.
+
+ An NBDD may not be capable of sending a NetBIOS datagram to a
+ particular NetBIOS name, including the broadcast NetBIOS name ("*")
+ defined above. A query mechanism is available to the end- node to
+ determine if a NBDD will be able to relay a datagram to a given name.
+ Before a datagram, or its fragments, are sent to the NBDD the P or M
+ node may send a DATAGRAM QUERY REQUEST packet to the NBDD with the
+ DESTINATION_NAME from the DATAGRAM SERVICE packet(s). The NBDD will
+ respond with a DATAGRAM POSITIVE QUERY RESPONSE if it will relay
+ datagrams to the specified destination name. After a positive
+ response the end-node unicasts the datagram to the NBDD. If the NBDD
+ will not be able to relay a datagram to the destination name
+ specified in the query, a DATAGRAM NEGATIVE QUERY RESPONSE packet is
+ returned. If the NBDD can not distribute a datagram, the end-node
+ then has the option of getting the name's owner list from the NBNS
+ and sending the datagram directly to each of the owners.
+
+ An NBDD must be able to respond to DATAGRAM QUERY REQUEST packets.
+ The response may always be positive. However, the usage or
+ implementation of the query mechanism by a P or M node is optional.
+ An implementation may always unicast the NetBIOS datagram to the NBDD
+ without asking if it will be relayed. Except for the datagram query
+ facility described above, an NBDD provides no feedback to indicate
+ whether it forwarded a datagram.
+
+18. NODE CONFIGURATION PARAMETERS
+
+ - B NODES:
+ - Node's permanent unique name
+ - Whether IGMP is in use
+ - Broadcast IP address to use
+
+
+
+NetBIOS Working Group [Page 58]
+
+RFC 1001 March 1987
+
+
+ - Whether NetBIOS session keep-alives are needed
+ - Usable UDP data field length (to control fragmentation)
+ - P NODES:
+ - Node's permanent unique name
+ - IP address of NBNS
+ - IP address of NBDD
+ - Whether NetBIOS session keep-alives are needed
+ - Usable UDP data field length (to control fragmentation)
+ - M NODES:
+ - Node's permanent unique name
+ - Whether IGMP is in use
+ - Broadcast IP address to use
+ - IP address of NBNS
+ - IP address of NBDD
+ - Whether NetBIOS session keep-alives are needed
+ - Usable UDP data field length (to control fragmentation)
+
+
+19. MINIMAL CONFORMANCE
+
+ To ensure multi-vendor interoperability, a minimally conforming
+ implementation based on this specification must observe the following
+ rules:
+
+ a) A node designed to work only in a broadcast area must
+ conform to the B node specification.
+
+ b) A node designed to work only in an internet must conform to
+ the P node specification.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+NetBIOS Working Group [Page 59]
+
+RFC 1001 March 1987
+
+
+
+REFERENCES
+
+
+ [1] "Protocol Standard For a NetBIOS Service on a TCP/UDP
+ Transport: Detailed Specifications", RFC 1002, March 1987.
+
+ [2] IBM Corp., "IBM PC Network Technical Reference Manual", No.
+ 6322916, First Edition, September 1984.
+
+ [3] J. Postel (Ed.), "Transmission Control Protocol", RFC 793,
+ September 1981.
+
+ [4] MIL-STD-1778
+
+ [5] J. Postel, "User Datagram Protocol", RFC 768, 28 August
+ 1980.
+
+ [6] J. Reynolds, J. Postel, "Assigned Numbers", RFC 990,
+ November 1986.
+
+ [7] J. Postel, "Internet Protocol", RFC 791, September 1981.
+
+ [8] J. Mogul, "Internet Subnets", RFC 950, October 1984
+
+ [9] J. Mogul, "Broadcasting Internet Datagrams in the Presence
+ of Subnets", RFC 922, October 1984.
+
+ [10] J. Mogul, "Broadcasting Internet Datagrams", RFC 919,
+ October 1984.
+
+ [11] P. Mockapetris, "Domain Names - Concepts and Facilities",
+ RFC 882, November 1983.
+
+ [12] P. Mockapetris, "Domain Names - Implementation and
+ Specification", RFC 883, November 1983.
+
+ [13] P. Mockapetris, "Domain System Changes and Observations",
+ RFC 973, January 1986.
+
+ [14] C. Partridge, "Mail Routing and the Domain System", RFC 974,
+ January 1986.
+
+ [15] S. Deering, D. Cheriton, "Host Groups: A Multicast Extension
+ to the Internet Protocol", RFC 966, December 1985.
+
+ [16] S. Deering, "Host Extensions for IP Multicasting", RFC 988,
+ July 1986.
+
+
+
+
+
+
+NetBIOS Working Group [Page 60]
+
+RFC 1001 March 1987
+
+
+APPENDIX A
+
+
+ This appendix contains supporting technical discussions. It is not
+ an integral part of the NetBIOS-over-TCP specification.
+
+ INTEGRATION WITH INTERNET GROUP MULTICASTING
+
+ The Netbios-over-TCP system described in this RFC may be easily
+ integrated with the Internet Group Multicast system now being
+ developed for the internet.
+
+ In the main body of the RFC, the notion of a broadcast area was
+ considered to be a single MAC-bridged "B-LAN". However, the
+ protocols defined will operate over an extended broadcast area
+ resulting from the creation of a permanent Internet Multicast Group.
+
+ Each separate broadcast area would be based on a separate permanent
+ Internet Multicast Group. This multicast group address would be used
+ by B and M nodes as their BROADCAST_ADDRESS.
+
+ In order to base the broadcast area on a multicast group certain
+ additional procedures are required and certain constraints must be
+ met.
+
+A-1. ADDITIONAL PROTOCOL REQUIRED IN B AND M NODES
+
+ All B or M nodes operating on an IGMP based broadcast area must have
+ IGMP support in their IP layer software. These nodes must perform an
+ IGMP join operation to enter the IGMP group before engaging in
+ NetBIOS activity.
+
+A-2. CONSTRAINTS
+
+ Broadcast Areas may overlap. For this reason, end-nodes must be
+ careful to examine the NetBIOS scope identifiers in all received
+ broadcast packets.
+
+ The NetBIOS broadcast protocols were designed for a network that
+ exhibits a low average transit time and low rate of packet loss. An
+ IGMP based broadcast area must exhibit these characteristics. In
+ practice this will tend to constrain IGMP broadcast areas to a campus
+ of networks interconnected by high-speed routers and inter-router
+ links. It is unlikely that transcontinental broadcast areas would
+ exhibit the required characteristics.
+
+
+
+
+
+
+
+
+
+NetBIOS Working Group [Page 61]
+
+RFC 1001 March 1987
+
+
+APPENDIX B
+
+
+ This appendix contains supporting technical discussions. It is not
+ an integral part of the NetBIOS-over-TCP specification.
+
+IMPLEMENTATION CONSIDERATIONS
+
+B-1. IMPLEMENTATION MODELS
+
+ On any participating system, there must be some sort of NetBIOS
+ Service to coordinate access by NetBIOS applications on that system.
+
+ To analyze the impact of the NetBIOS-over-TCP architecture, we use
+ the following three models of how a NetBIOS service might be
+ implemented:
+
+ 1. Combined Service and Application Model
+
+ The NetBIOS service and application are both contained
+ within a single process. No interprocess communication is
+ assumed within the system; all communication is over the
+ network. If multiple applications require concurrent access
+ to the NetBIOS service, they must be folded into this
+ monolithic process.
+
+
+ 2. Common Kernel Element Model
+
+ The NetBIOS Service is part of the operating system (perhaps
+ as a device driver or a front-end processor). The NetBIOS
+ applications are normal operating system application
+ processes. The common element NetBIOS service contains all
+ the information, such as the name and listen tables,
+ required to co-ordinate the activities of the applications.
+
+
+ 3. Non-Kernel Common Element Model
+
+ The NetBIOS Service is implemented as an operating system
+ application process. The NetBIOS applications are other
+ operating system application processes. The service and the
+ applications exchange data via operating system interprocess
+ communication. In a multi-processor (e.g. network)
+ operating system, each module may reside on a different cpu.
+ The NetBIOS service process contains all the shared
+ information required to coordinate the activities of the
+ NetBIOS applications. The applications may still require a
+ subroutine library to facilitate access to the NetBIOS
+ service.
+
+
+
+
+NetBIOS Working Group [Page 62]
+
+RFC 1001 March 1987
+
+
+ For any of the implementation models, the TCP/IP service can be
+ located in the operating system or split among the NetBIOS
+ applications and the NetBIOS service processes.
+
+B-1.1 MODEL INDEPENDENT CONSIDERATIONS
+
+ The NetBIOS name service associates a NetBIOS name with a host. The
+ NetBIOS session service further binds the name to a specific TCP port
+ for the duration of the session.
+
+ The name service does not need to be informed of every Listen
+ initiation and completion. Since the names are not bound to any TCP
+ port in the name service, the session service may use a different tcp
+ port for each session established with the same local name.
+
+ The TCP port used for the data transfer phase of a NetBIOS session
+ can be globally well-known, locally well-known, or ephemeral. The
+ choice is a local implementation issue. The RETARGET mechanism
+ allows the binding of the NetBIOS session to a TCP connection to any
+ TCP port, even to another IP node.
+
+ An implementation may use the session service's globally well- known
+ TCP port for the data transfer phase of the session by not using the
+ RETARGET mechanism and, rather, accepting the session on the initial
+ TCP connection. This is permissible because the caller always uses
+ an ephemeral TCP port.
+
+ The complexity of the called end RETARGET mechanism is only required
+ if a particular implementation needs it. For many real system
+ environments, such as an in-kernel NetBIOS service implementation, it
+ will not be necessary to retarget incoming calls. Rather, all
+ NetBIOS sessions may be multiplexed through the single, well-known,
+ NetBIOS session service port. These implementations will not be
+ burdened by the complexity of the RETARGET mechanism, nor will their
+ callers be required to jump through the retargetting hoops.
+
+ Nevertheless, all callers must be ready to process all possible
+ SESSION RETARGET RESPONSEs.
+
+B-1.2 SERVICE OPERATION FOR EACH MODEL
+
+ It is possible to construct a NetBIOS service based on this
+ specification for each of the above defined implementation models.
+
+ For the common kernel element model, all the NetBIOS services, name,
+ datagram, and session, are simple. All the information is contained
+ within a single entity and can therefore be accessed or modified
+ easily. A single port or multiple ports for the NetBIOS sessions can
+ be used without adding any significant complexity to the session
+ establishment procedure. The only penalty is the amount of overhead
+ incurred to get the NetBIOS messages and operation requests/responses
+
+
+
+NetBIOS Working Group [Page 63]
+
+RFC 1001 March 1987
+
+
+ through the user and operating system boundary.
+
+ The combined service and application model is very similar to the
+ common kernel element model in terms of its requirements on the
+ NetBIOS service. The major difficulty is the internal coordination
+ of the multiple NetBIOS service and application processes existing in
+ a system of this type.
+
+ The NetBIOS name, datagram and session protocols assume that the
+ entities at the end-points have full control of the various well-
+ known TCP and UDP ports. If an implementation has multiple NetBIOS
+ service entities, as would be the case with, for example, multiple
+ applications each linked into a NetBIOS library, then that
+ implementation must impose some internal coordination.
+ Alternatively, use of the NetBIOS ports could be periodically
+ assigned to one application or another.
+
+ For the typical non-kernel common element mode implementation, three
+ permanent system-wide NetBIOS service processes would exist:
+
+ - The name server
+ - the datagram server
+ - and session server
+
+ Each server would listen for requests from the network on a UDP or
+ TCP well-known port. Each application would have a small piece of
+ the NetBIOS service built-in, possibly a library. Each application's
+ NetBIOS support library would need to send a message to the
+ particular server to request an operation, such as add name or send a
+ datagram or set-up a listen.
+
+ The non-kernel common element model does not require a TCP connection
+ be passed between the two processes, session server and application.
+ The RETARGET operation for an active NetBIOS Listen could be used by
+ the session server to redirect the session to another TCP connection
+ on a port allocated and owned by the application's NetBIOS support
+ library. The application with either a built-in or a kernel-based
+ TCP/IP service could then accept the RETARGETed connection request
+ and process it independently of the session server.
+
+ On Unix(tm) or POSIX(tm), the NetBIOS session server could create
+ sub-processes for incoming connections. The open sessions would be
+ passed through "fork" and "exec" to the child as an open file
+ descriptor. This approach is very limited, however. A pre- existing
+ process could not receive an incoming call. And all call-ed
+ processes would have to be sub-processes of the session server.
+
+B-2. CASUAL AND RESTRICTED NetBIOS APPLICATIONS
+
+ Because NetBIOS was designed to operate in the open system
+ environment of the typical personal computer, it does not have the
+
+
+
+NetBIOS Working Group [Page 64]
+
+RFC 1001 March 1987
+
+
+ concept of privileged or unprivileged applications. In many multi-
+ user or multi-tasking operating systems applications are assigned
+ privilege capabilities. These capabilities limit the applications
+ ability to acquire and use system resources. For these systems it is
+ important to allow casual applications, those with limited system
+ privileges, and privileged applications, those with 'super-user'
+ capabilities but access to them and their required resources is
+ restricted, to access NetBIOS services. It is also important to
+ allow a systems administrator to restrict certain NetBIOS resources
+ to a particular NetBIOS application. For example, a file server
+ based on the NetBIOS services should be able to have names and TCP
+ ports for sessions only it can use.
+
+ A NetBIOS application needs at least two local resources to
+ communicate with another NetBIOS application, a NetBIOS name for
+ itself and, typically, a session. A NetBIOS service cannot require
+ that NetBIOS applications directly use privileged system resources.
+ For example, many systems require privilege to use TCP and UDP ports
+ with numbers less than 1024. This RFC requires reserved ports for
+ the name and session servers of a NetBIOS service implementation. It
+ does not require the application to have direct access these reserved
+ ports.
+
+ For the name service, the manager of the local name table must have
+ access to the NetBIOS name service's reserved UDP port. It needs to
+ listen for name service UDP packets to defend and define its local
+ names to the network. However, this manager need not be a part of a
+ user application in a system environment which has privilege
+ restrictions on reserved ports.
+
+ The internal name server can require certain privileges to add,
+ delete, or use a certain name, if an implementer wants the
+ restriction. This restriction is independent of the operation of the
+ NetBIOS service protocols and would not necessarily prevent the
+ interoperation of that implementation with another implementation.
+
+ The session server is required to own a reserved TCP port for session
+ establishment. However, the ultimate TCP connection used to transmit
+ and receive data does not have to be through that reserved port. The
+ RETARGET procedure the NetBIOS session to be shifted to another TCP
+ connection, possibly through a different port at the called end.
+ This port can be an unprivileged resource, with a value greater than
+ 1023. This facilitates casual applications.
+
+ Alternately, the RETARGET mechanism allows the TCP port used for data
+ transmission and reception to be a reserved port. Consequently, an
+ application wishing to have access to its ports maintained by the
+ system administrator can use these restricted TCP ports. This
+ facilitates privileged applications.
+
+ A particular implementation may wish to require further special
+
+
+
+NetBIOS Working Group [Page 65]
+
+RFC 1001 March 1987
+
+
+ privileges for session establishment, these could be associated with
+ internal information. It does not have to be based solely on TCP
+ port allocation. For example, a given NetBIOS name may only be used
+ for sessions by applications with a certain system privilege level.
+
+ The decision to use reserved or unreserved ports or add any
+ additional name registration and usage authorization is a purely
+ local implementation decision. It is not required by the NetBIOS
+ protocols specified in the RFC.
+
+B-3. TCP VERSUS SESSION KEEP-ALIVES
+
+ The KEEP-ALIVE is a protocol element used to validate the existence
+ of a connection. A packet is sent to the remote connection partner
+ to solicit a response which shows the connection is still
+ functioning. TCP KEEP-ALIVES are used at the TCP level on TCP
+ connections while session KEEP-ALIVES are used on NetBIOS sessions.
+ These protocol operations are always transparent to the connection
+ user. The user will only find out about a KEEP-ALIVE operation if it
+ fails, therefore, if the connection is lost.
+
+ The NetBIOS specification[2] requires the NetBIOS service to inform
+ the session user if a session is lost when it is in a passive or
+ active state. Therefore,if the session user is only waiting for a
+ receive operation and the session is dropped the NetBIOS service must
+ inform the session user. It cannot wait for a session send operation
+ before it informs the user of the loss of the connection.
+
+ This requirement stems from the management of scarce or volatile
+ resources by a NetBIOS application. If a particular user terminates
+ a session with a server application by destroying the client
+ application or the NetBIOS service without a NetBIOS Hang Up, the
+ server application will want to clean-up or free allocated resources.
+ This server application if it only receives and then sends a response
+ requires the notification of the session abort in the passive state.
+
+ The standard definition of a TCP service cannot detect loss of a
+ connection when it is in a passive state, waiting for a packet to
+ arrive. Some TCP implementations have added a KEEP-ALIVE operation
+ which is interoperable with implementations without this feature.
+ These implementations send a packet with an invalid sequence number
+ to the connection partner. The partner, by specification, must
+ respond with a packet showing the correct sequence number of the
+ connection. If no response is received from the remote partner
+ within a certain time interval then the TCP service assumes the
+ connection is lost.
+
+ Since many TCP implementations do not have this KEEP-ALIVE function
+ an optional NetBIOS KEEP-ALIVE operation has been added to the
+ NetBIOS session protocols. The NetBIOS KEEP-ALIVE uses the
+ properties of TCP to solicit a response from the remote connection
+
+
+
+NetBIOS Working Group [Page 66]
+
+RFC 1001 March 1987
+
+
+ partner. A NetBIOS session message called KEEP-ALIVE is sent to the
+ remote partner. Since this results in TCP sending an IP packet to
+ the remote partner, the TCP connection is active. TCP will discover
+ if the TCP connection is lost if the remote TCP partner does not
+ acknowledge the IP packet. Therefore, the NetBIOS session service
+ does not send a response to a session KEEP ALIVE message. It just
+ throws it away. The NetBIOS session service that transmits the KEEP
+ ALIVE is informed only of the failure of the TCP connection. It does
+ not wait for a specific response message.
+
+ A particular NetBIOS implementation should use KEEP-ALIVES if it is
+ concerned with maintaining compatibility with the NetBIOS interface
+ specification[2]. Compatibility is especially important if the
+ implementation wishes to support existing NetBIOS applications, which
+ typically require the session loss detection on their servers, or
+ future applications which were developed for implementations with
+ session loss detection.
+
+B-4. RETARGET ALGORITHMS
+
+ This section contains 2 suggestions for RETARGET algorithms. They
+ are called the "straight" and "stack" methods. The algorithm in the
+ body of the RFC uses the straight method. Implementation of either
+ algorithm must take into account the Session establishment maximum
+ retry count. The retry count is the maximum number of TCP connect
+ operations allowed before a failure is reported.
+
+ The straight method forces the session establishment procedure to
+ begin a retry after a retargetting failure with the initial node
+ returned from the name discovery procedure. A retargetting failure
+ is when a TCP connection attempt fails because of a time- out or a
+ NEGATIVE SESSION RESPONSE is received with an error code specifying
+ NOT LISTENING ON CALLED NAME. If any other failure occurs the
+ session establishment procedure should retry from the call to the
+ name discovery procedure.
+
+ A minimum of 2 retries, either from a retargetting or a name
+ discovery failure. This will give the session service a chance to
+ re-establish a NetBIOS Listen or, more importantly, allow the NetBIOS
+ scope, local name service or the NBNS, to re-learn the correct IP
+ address of a NetBIOS name.
+
+ The stack method operates similarly to the straight method. However,
+ instead of retrying at the initial node returned by the name
+ discovery procedure, it restarts with the IP address of the last node
+ which sent a SESSION RETARGET RESPONSE prior to the retargetting
+ failure. To limit the stack method, any one host can only be tried a
+ maximum of 2 times.
+
+
+
+
+
+
+NetBIOS Working Group [Page 67]
+
+RFC 1001 March 1987
+
+
+B-5. NBDD SERVICE
+
+ If the NBDD does not forward datagrams then don't provide Group and
+ Broadcast NetBIOS datagram services to the NetBIOS user. Therefore,
+ ignore the implementation of the query request and, when get a
+ negative response, acquiring the membership list of IP addresses and
+ sending the datagram as a unicast to each member.
+
+B-6. APPLICATION CONSIDERATIONS
+
+B-6.1 USE OF NetBIOS DATAGRAMS
+
+ Certain existing NetBIOS applications use NetBIOS datagrams as a
+ foundation for their own connection-oriented protocols. This can
+ cause excessive NetBIOS name query activity and place a substantial
+ burden on the network, server nodes, and other end- nodes. It is
+ recommended that this practice be avoided in new applications.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+NetBIOS Working Group [Page 68]
+