brian@ucsd.EDU (Brian Kantor) (02/20/88)
---
on. 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]