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]
`
`Page 1 of 68
`
`LG Electronics Exhibit 1031
`
`

`

`RFC 1001
`
`March 1987
`
`SUMMARY OF CONTENTS
`
`STATUS OF THIS MEMO
`1.
`ACKNOWLEDGEMENTS
`2.
`INTRODUCTION
`3.
`DESIGN PRINCIPLES
`4.
`OVERVIEW OF NetBIOS
`5.
`6. NetBIOS FACILITIES SUPPORTED BY THIS STANDARD
`
`REQUIRED SUPPORTING SERVICE INTERFACES AND DEFINITIONS
`7.
`RELATED PROTOCOLS AND SERVICES
`8.
`9. NetBIOS SCOPE
`10. NetBIOS END—NODES
`11. NetBIOS SUPPORT SERVERS
`12.
`TOPOLOGIES
`13.
`GENERAL METHODS
`14.
`REPRESENTATION OF NETBIOS NAMES
`15. NetBIOS NAME SERVICE
`16. NetBIOS SESSION SERVICE
`17.
`NETBIOS DATAGRAM SERVICE
`18.
`NODE CONFIGURATION PARAMETERS
`19. MINIMAL CONFORMANCE
`REFERENCES
`APPENDIX A — INTEGRATION WITH INTERNET GROUP MULTICASTING
`APPENDIX B — IMPLEMENTATION CONSIDERATIONS
`
`6
`6
`T
`7
`10
`15
`
`15
`16
`16
`16
`18
`20
`23
`25
`27
`48
`55
`58
`59
`60
`61
`62
`
`NetBIOS Working Group
`
`[Page 2]
`
`Page 2 of 68
`
`

`

`RFC 1001
`
`March 1987
`
`TABLE OF CONTENTS
`
`1.
`
`STATUS OF THIS MEMO
`
`2.
`
`ACKNOWLEDGEMENTS
`
`3.
`
`INTRODUCTION
`
`4.
`
`DESIGN PRINCIPLES
`4.1
`PRESERVE NetBIOS SERVICES
`4.2 USE EXISTING STANDARDS
`4.3 MINIMIZE OPTIONS
`4.4
`TOLERATE ERRORS AND DISRUPTIONS
`
`DO NOT REQUIRE CENTRAL MANAGEMENT
`4.5
`4.6 ALLOW INTERNET OPERATION
`4.7 MINIMIZE BROADCAST ACTIVITY
`4.8
`PERMIT IMPLEMENTATION ON EXISTING SYSTEMS
`
`4.9 REQUIRE ONLY THE MINIMUM NECESSARY TO OPERATE
`4.10 MAXIMIZE EFFICIENCY
`4.11 MINIMIZE NEW INVENTIONS
`
`5.
`
`OVERVIEW OF NetBIOS
`5.1
`INTERFACE TO APPLICATION PROGRAMS
`5.2 NAME SERVICE
`5.3
`SESSION SERVICE
`5.4
`DATAGRAM SERVICE
`5.5 MISCELLANEOUS FUNCTIONS
`5.6 NON—STANDARD EXTENSIONS
`
`6. NetBIOS FACILITIES SUPPORTED BY THIS STANDARD
`
`7.
`
`8.
`
`REQUIRED SUPPORTING SERVICE INTERFACES AND DEFINITIONS
`
`RELATED PROTOCOLS AND SERVICES
`
`9. NetBIOS SCOPE
`
`10. NetBIOS END—NODES
`
`BROADCAST (B) NODES
`10.1
`POINT—TO—POINT (P) NODES
`10.2
`10.3 MIXED MODE (M) NODES
`
`11. NetBIOS SUPPORT SERVERS
`
`11.1 NetBIOS NAME SERVER (NBNS) NODES
`11.1.1 RELATIONSHIP OF THE NBNS TO THE DOMAIN NAME SYSTEM
`
`11.2 NetBIOS DATAGRAM DISTRIBUTION SERVER (NBDD) NODES
`11.3 RELATIONSHIP OF NBNS AND NBDD NODES
`11.4 RELATIONSHIP OF NetBIOS SUPPORT SERVERS AND B NODES
`12.
`TOPOLOGIES
`12.1
`LOCAL
`
`6
`
`6
`
`--..1
`
`8
`8
`8
`8
`8
`
`9
`9
`9
`9
`
`9
`10
`10
`
`10
`10
`11
`12
`13
`14
`15
`
`15
`
`15
`
`16
`
`16
`
`16
`
`16
`16
`16
`
`18
`
`18
`19
`
`19
`20
`20
`20
`20
`
`NetBIOS Working Group
`
`[Page 3]
`
`Page 3 of 68
`
`

`

`RFC 1001
`
`March 1987
`
`12.1.1 B NODES ONLY
`12.1.2 P NODES ONLY
`12.1.3 MIXED B AND P NODES
`12.2
`INTERNET
`12.2.1 P NODES ONLY
`12.2.2 MIXED M AND P NODES
`
`13.
`
`GENERAL METHODS
`
`13.1 REQUEST/RESPONSE INTERACTION STYLE
`13.1.1 RETRANSMISSION OF REQUESTS
`13.1.2 REQUESTS WITHOUT RESPONSES: DEMANDS
`13.2
`TRANSACTIONS
`13.2.1 TRANSACTION ID
`13.3
`TCP AND UDP FOUNDATIONS
`
`REPRESENTATION OF NETBIOS NAMES
`14.
`14.1
`FIRST LEVEL ENCODING
`14.2
`SECOND LEVEL ENCODING
`
`15. NetBIOS NAME SERVICE
`15.1
`OVERVIEW OF NetBIOS NAME SERVICE
`
`15.1.1 NAME REGISTRATION (CLAIM)
`15.1.2 NAME QUERY (DISCOVERY)
`15.1.3 NAME RELEASE
`15.1.3.1 EXPLICIT RELEASE
`15.1.3.2 NAME LIFETIME AND REFRESH
`15.1.3.3 NAME CHALLENGE
`15.1.3.4 GROUP NAME FADE—OUT
`15.1.3.5 NAME CONFLICT
`15.1.4 ADAPTER STATUS
`15.1.5 END—NODE NBNS INTERACTION
`
`15.1.5.1 UDP, TCP, AND TRUNCATION
`15.1.5.2 NBNS WACK
`15.1.5.3 NBNS REDIRECTION
`15.1.6 SECURED VERSUS NON—SECURED NBNS
`15.1.7 CONSISTENCY OF THE NBNS DATA BASE
`15.1.8 NAME CACHING
`15.2
`NAME REGISTRATION TRANSACTIONS
`15.2.1 NAME REGISTRATION BY B NODES
`15.2.2 NAME REGISTRATION BY P NODES
`
`15.2.2.1 NEW NAME, OR NEW GROUP MEMBER
`15.2.2.2 EXISTING NAME AND OWNER IS STILL ACTIVE
`15.2.2.3 EXISTING NAME AND OWNER IS INACTIVE
`15.2.3 NAME REGISTRATION BY M NODES
`
`NAME QUERY TRANSACTIONS
`15.3
`15.3.1 QUERY BY B NODES
`15.3.2 QUERY BY P NODES
`15.3.3 QUERY BY M NODES
`15.3.4 ACQUIRE GROUP MEMBERSHIP LIST
`15.4
`NAME RELEASE TRANSACTIONS
`15.4.1 RELEASE BY B NODES
`
`21
`21
`21
`22
`22
`23
`
`23
`
`23
`24
`24
`25
`25
`25
`
`25
`26
`27
`
`27
`27
`
`27
`28
`28
`28
`29
`29
`29
`30
`31
`31
`
`31
`32
`32
`32
`32
`34
`34
`34
`35
`
`35
`36
`37
`38
`
`39
`39
`40
`43
`43
`44
`44
`
`NetBIOS Working Group
`
`[Page 4]
`
`Page 4 of 68
`
`

`

`RFC 1001
`
`March 1987
`
`15.4.2 RELEASE BY P NODES
`15.4.3 RELEASE BY M NODES
`15.5
`NAME MAINTENANCE TRANSACTIONS
`15.5.1 NAME REFRESH
`15.5.2 NAME CHALLENGE
`15.5.3 CLEAR NAME CONFLICT
`15.6 ADAPTER STATUS TRANSACTIONS
`
`16. NetBIOS SESSION SERVICE
`16.1
`OVERVIEW OF NetBIOS SESSION SERVICE
`16.1.1 SESSION ESTABLISHMENT PHASE OVERVIEW
`16.1.1.1 RETRYING AFTER BEING RETARGETTED
`16.1.1.2 SESSION ESTABLISHMENT TO A GROUP NAME
`16.1.2 STEADY STATE PHASE OVERVIEW
`16.1.3 SESSION TERMINATION PHASE OVERVIEW
`16.2
`SESSION ESTABLISHMENT PHASE
`16.3
`SESSION DATA TRANSFER PHASE
`16.3.1 DATA ENCAPSULATION
`16.3.2 SESSION KEEP—ALIVES
`
`NETBIOS DATAGRAM SERVICE
`17.
`17.1
`OVERVIEW OF NetBIOS DATAGRAM SERVICE
`
`17.1.1 UNICAST, MULTICAST, AND BROADCAST
`17.1.2 FRAGMENTATION OF NetBIOS DATAGRAMS
`17.2 NetBIOS DATAGRAMS BY B NODES
`17.3 NetBIOS DATAGRAMS BY P AND M NODES
`
`18.
`
`NODE CONFIGURATION PARAMETERS
`
`19. MINIMAL CONFORMANCE
`
`REFERENCES
`
`APPENDIX A
`
`INTEGRATION WITH INTERNET GROUP MULTICASTING
`
`A—1.
`A—2.
`
`ADDITIONAL PROTOCOL REQUIRED IN B AND M NODES
`CONSTRAINTS
`
`APPENDIX B
`
`IMPLEMENTATION CONSIDERATIONS
`B—l.
`IMPLEMENTATION MODELS
`B—1.1 MODEL INDEPENDENT CONSIDERATIONS
`B—1.2
`SERVICE OPERATION FOR_EACH MODEL
`B—2.
`CASUAL AND RESTRICTED NetBIOS APPLICATIONS
`B—3.
`TCP VERSUS SESSION KEEP—ALIVES
`B—4.
`RETARGET ALGORITHMS
`B—5.
`NBDD SERVICE
`B—6. APPLICATION CONSIDERATIONS
`B—6.1 USE OF NetBIOS DATAGRAMS
`
`44
`44
`45
`45
`46
`47
`47
`
`48
`49
`49
`50
`51
`51
`51
`52
`54
`54
`54
`
`55
`55
`
`55
`55
`57
`58
`
`58
`
`59
`
`60
`
`61
`
`61
`
`61
`61
`
`62
`
`62
`62
`63
`63
`64
`66
`67
`68
`68
`68
`
`NetBIOS Working Group
`
`[Page 5]
`
`Page 5 of 68
`
`

`

`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: mtxinu1excelan1avnish@ucbvax.berkeley.edu
`Usenet:
`ucbvaxlmtxinu!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
`Geoffrey Arnold
`Keith Ball
`
`Richard Cherry
`Greg Ennis
`David Kaufman
`
`Dan Lynch
`Steve Thomas
`
`Arvind Agrawal
`Karl Auerbach
`Amatzia Ben—Artzi
`
`Lorenzo Aguilar
`K. Ramesh Babu
`Vint Cerf
`
`David Crocker
`Steve Holmgren
`Lee LaBarre
`
`Gaylord Miyata
`Ishan Wu
`
`Steve Deering
`Jay Israel
`James Lau
`
`David Stevens
`
`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]
`
`Page 6 of 68
`
`

`

`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"[l] 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.
`
`For
`NOTE: various symbolic values are used in this document.
`their definitions, refer to the Detailed Specifications[1].
`
`NetBIOS Working Group
`
`[Page 7]
`
`Page 7 of 68
`
`

`

`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
`
`the
`In the absence of an "official" standard for NetBIOS services,
`version found in the IBM PC Network Technical Reference[2]
`is used.
`
`NetBIOS is the foundation of a large body of existing applications.
`It is desirable to operate these applications on TCP networks and 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
`
`is a demanding
`Protocol development, especially with standardization,
`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.
`
`the options should be designed so that
`Where options are included,
`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]
`
`Page 8 of 68
`
`

`

`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.}
`
`the standard assumes that this form of operation will be
`However,
`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.
`
`the standard
`Despite the availability of broadcast capabilities,
`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]
`
`Page 9 of 68
`
`

`

`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.
`
`OVERVIEW OF NetBIOS
`
`It is for background
`This section describes the NetBIOS services.
`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]
`
`Page 10 of 68
`
`

`

`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 {*).
`
`The bid may be for
`Registration is a bid for use of a name.
`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
`
`It is
`The application no longer requires use of the name.
`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]
`
`Page 11 of 68
`
`

`

`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,011 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
`
`The listen primitive may be
`Accept a session from a caller.
`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
`
`A time—out can occur. A.time—out of
`Transmit one message.
`any session send forces the non—graceful termination of the
`session.
`
`NetBIOS Working Group
`
`[Page 12]
`
`Page 12 of 68
`
`

`

`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,
`sending and receiving names.
`
`the receiver of the datagram is told the
`
`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]
`
`Page 13 of 68
`
`

`

`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
`
`The successful cancel of a
`Abort a pending NetBIOS request.
`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]
`
`Page 14 of 68
`
`

`

`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
`
`is not a NetBIOS function.
`Remote Program Load (RPL)
`a NetBIOS application defined by IBM in their NetBIOS
`specification {see pages 2—80 through 2—82 in [2]).
`
`It is
`
`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]
`
`Page 15 of 68
`
`

`

`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[ll,l2,13,l4]
`—
`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:
`
`("B") nodes
`— Broadcast
`— 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]
`
`Page 16 of 68
`
`

`

`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.
`
`No matter how
`End—nodes may be combined in various topologies.
`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
`
`(or "B") nodes communicate using a mix of UDP datagrams
`Broadcast
`(both broadcast and directed} and TCP connections.
`B nodes may
`A
`freely interoperate with one another within a broadcast area.
`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
`
`(or "P") nodes communicate using only directed UDP
`Point—to—point
`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]
`
`Page 17 of 68
`
`

`

`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]
`
`Page 18 of 68
`
`

`

`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.
`
`the NetBIOS names are encoded in a form acceptable to the
`First,
`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.
`
`the negotiated responsibility mechanisms permit the NBNS to be
`Third,
`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.
`NBDD extends NetBIOS datagram distribution service to this
`environment.
`
`The
`
`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 dete