Tech-invite3GPPspecsGlossariesIETFRFCsGroupsSIPABNFsWorld Map

RFC 1001


Protocol standard for a NetBIOS service on a TCP/UDP transport: Concepts and methods

Part 3 of 3, p. 48 to 68
Prev RFC Part


prevText      Top      Up      ToC       Page 48 

   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.

Top      Up      ToC       Page 49 

   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

     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.


   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

     -  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

   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

Top      Up      ToC       Page 50 
        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

   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

   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.  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

Top      Up      ToC       Page 51 
   discussion of two such methods is in Appendix B, "Retarget

   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.


   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

   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.


   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

Top      Up      ToC       Page 52 
   of the loss of the session.  All data received up to the close
   indication should be delivered, if possible, to the session's user.


   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

Top      Up      ToC       Page 53 
                   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".

Top      Up      ToC       Page 54 
           CALLER                  LISTEN PROCESSOR        LISTENER

                   TCP CONNECT
                   TCP ACCEPT
                   SESSION REQUEST
                   REDIRECT RESPONSE
                   TCP CLOSE
                   TCP CLOSE

                       TCP CONNECT




   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.


   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

Top      Up      ToC       Page 55 
   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.



   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.


   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.


   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)

Top      Up      ToC       Page 56 
   The two name fields are in second level encoded format (see section

   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

Top      Up      ToC       Page 57 
          -  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.


   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

   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


   According to [2], a user may not provide a NetBIOS name beginning
   with "*".

   For each node in the broadcast area that receives the NetBIOS

Top      Up      ToC       Page 58 
   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.


   P and M nodes do not use IP broadcast to distribute NetBIOS

   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.


     -  B NODES:
          -  Node's permanent unique name
          -  Whether IGMP is in use
          -  Broadcast IP address to use

Top      Up      ToC       Page 59 
          -  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)


   To ensure multi-vendor interoperability, a minimally conforming
   implementation based on this specification must observe the following

   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.

Top      Up      ToC       Page 60 

      [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

      [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.

Top      Up      ToC       Page 61 

   This appendix contains supporting technical discussions.  It is not
   an integral part of the NetBIOS-over-TCP specification.


   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


   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.


   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.

Top      Up      ToC       Page 62 

   This appendix contains supporting technical discussions.  It is not
   an integral part of the NetBIOS-over-TCP specification.



   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

   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

Top      Up      ToC       Page 63 
   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.


   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


   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

Top      Up      ToC       Page 64 
   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.


   Because NetBIOS was designed to operate in the open system
   environment of the typical personal computer, it does not have the

Top      Up      ToC       Page 65 
   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

   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

Top      Up      ToC       Page 66 
   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.


   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

Top      Up      ToC       Page 67 
   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.


   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.

Top      Up      ToC       Page 68 

   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.



   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.