NetBIOS is often described as a "Session Layer" protocol and a variety of transport systems have been used in different implementations. Particularly because NetBIOS is a non-routable protocol, it has often been implemented using other routable protocols to provide the transport.
It has traditionally been the NetBIOS API that has been the "standard". In most implementations (certainly NetBIOS over TCP/IP and NetBIOS over IPX), encapsulation has been implemented to ensure that higher level protocols (such as SMB) can run over the encapsulated protocol in the same way as they would run over NetBIOS Frames Protocol, NBF (otherwise known as NetBEUI or NetBIOS). Thus it is important to understand the NetBIOS Frames Protocol, NBF in order to understand the various encapsulation implementations.
The suite of protocols known as "TCP/IP" is perhaps the best know protocol suite. Currently most systems use IP version 4; the next generation of IP, IPv6 is not yet in widespread use. These protocols are well documented in "Request for Comments" (RFCs) and there are many books available on the subject.
NetBIOS can be carried over TCP/IP (v4) networks. The relevant RFCs describing NetBIOS on a TCP and UDP foundation are:
The protocol standards described in the above RFCs are designed to preserve existing NetBIOS services, utilise existing standards and minimise new developments. The standards proposed also aimed to be robust and efficient while not necessarily requiring central management or many additional facilities to run.
Within this system NetBIOS names are aligned with the Domain Name Service (DNS). A "NetBIOS Scope" is defined as a population of computers through out which a NetBIOS name is known. Because many non-intersecting NetBIOS Scopes may exist on an internetwork, each NetBIOS scope has a "scope identifier"; this is a string which is in a DNS compatible format. This can be thought of as a pseudo sub-domain containing all the NetBIOS names in a given Scope.
NetBIOS names are strings of 16 bytes with few restrictions; NetBIOS names can and often do contain characters which are illegal in DNS names such as spaces, underscores and other non-alphanumeric characters. DNS names may only contain alphanumeric characters, hyphens and stops. An encoding scheme is used to represent the 16 byte NetBIOS names as a 32 character string to which a stop and then the scope identifier is appended to form a DNS name. Each name needs to be registered for use with an IP address.
There are two servers defined which may be implemented with NetBIOS on a TCP/UDP transport: The NetBIOS Name Server (NBNS) and the NetBIOS Datagram Distribution Server (NBDD).
The NBNS can be configured to work in a variety of ways either acting simply as a bulletin board where systems can register names, or completely managing names and addresses. Several NBNS system can be configured to work together to provide a distributed service.
Since multicasting and broadcasting are not widely implemented on internets, the NBDD service provides this function. Datagrams to be sent to individual nodes or broadcast, can be sent to the NBDD which will forward the datagram to the target node or nodes.
Systems implementing NetBIOS on a TCP/UDP transport, other than NBNS and NBDS servers, are known as "End-Nodes". Two distinct types of "End-Node" are defined: Broadcast nodes ("B" nodes) and Point-to-point nodes ("P" nodes). Broadcast nodes ("B" nodes) communicate using a combination of UDP datagrams and TCP connections. "B" nodes can function within a broadcast area which is a single MAC-bridged LAN. Point-to-point nodes communicate exclusively by directed UDP datagrams and TCP sessions. "P" nodes depend upon NBNS servers to register their name to IP address mappings and discover the names of other End-Nodes.
Two further kinds of End-Node are used with NetBIOS on a TCP/UDP transport: RFC 1001 defines Mixed mode nodes ("M" nodes) as "P" nodes with "B" node characteristics. "M" nodes use NBNS and NBDD servers, but may continue to function if these servers are temporarily unavailable. An "M" node typically performs functions as a "B" node and then as a "P" node if necessary. Hybrid nodes ("H" nodes) are not defined in RFC 1001 and have not been standardised; these are mixed nodes similar to "M" nodes but function broadly in the opposite manner to "M" nodes. "H" nodes function as a "P" node first and then as a "B" node.
NetBIOS on a TCP/UDP transport provides the standard NetBIOS services: Adapter Status Transactions, NetBIOS Session Service and NetBIOS Datagram Service.
Details of packet formats are given in RFC 1002.
The following UDP and TCP port numbers are used with NetBIOS on a TCP/UDP transport:
| Service | UDP Port | TCP Port |
|---|---|---|
| Name Service | 137 | 137 |
| Session Service | 139 | |
| Datagram Service | 138 |
There are several implementations of NetBIOS on a TCP/UDP transport. A free implementation is "SAMBA" which is available for various Unix platforms and non-Unix platforms. Further information about "SAMBA" can be obtained from the "SAMBA" Web page:
The product can be obtained from the above web site which is also a useful source of information.
NetBIOS over TCP/IP is probably the most common implementation and is often used in preference to NetBIOS "on the wire" (NetBIOS Frames Protocol otherwise known as NetBEUI or just NetBIOS) or in preference to NetBIOS over IPX/SPX. NetBIOS over TCP/IP is also probably most often used to carry the SMB protocol.
When implementing NetBIOS over TCP/IP, Name resolution i.e. the mechanisms for converting NetBIOS names to IP addresses is critically important. This topic is sufficiently important (and so often the source of many problems) to merit special discussion.
It is important to note that Name resolution is separate from the Browser service. Name resolution is specific to NetBIOS over TCP/IP; the Browser service runs over SMB which runs over NetBIOS Frames Protocol, NetBIOS over IPX or NetBIOS over TCP/IP. The mapping of NetBIOS names to IP addresses is distinct from the service that makes lists of systems available (for example in "Network Neighborhood" or "My Network Places") which is provided by the Browser service. Of course services such as the Browser service (that runs over SMB) are unlikely to function correctly if the underlying facilities such as Name resolution are not working properly.
The Name resolution mechanisms discussed here do not necessarily conflict with the mechanisms discussed in the standards RFC 1001 and RFC 1002, but can be seen as alternative implementations with various enhancements.
In practice it seems that the main implementations of NetBIOS over TCP/IP utilize a local cache for Name resolution; name to IP address mappings that have recently been resolved are held in a local cache for a short time which can reduce the need to access the network to resolve names to IP addresses.
Many implementations of NetBIOS over TCP/IP make use of an LMHOSTS file. The LMHOSTS file is similar to the traditional hosts file; both are simple text files listing IPv4 addresses and host names. The LMHOSTS file consists of several lines each of which may have an IPv4 address followed by white space, a NetBIOS name and possibly additional parameters or comments. Most implementations support the use of the hash # character to indicate comments or additional parameters. While the basic structure described above is fairly universal, the use of additional information is implementation dependant.
In the SAMBA implementation a NetBIOS hostname can be followed by a hash # and then two hexadecimal digits specifying the NetBIOS name type. In the Microsoft implementation, special characters can be included by enclosing the name in quotes and entering the hexadecimal code as \0xnn or \nn; the sixteenth byte can be specified in this manner but the name must be padded with spaces to ensure it is sixteen bytes long. In the Microsoft implementation several "directives" can be included in the file, beginning with the hash # character.
Microsoft has produced articles describing their use of LMHOSTS files including:
The NetBIOS Name Service is implemented in SAMBA as nmbd. This service can also support the browsing service (which is a separate service). The nmbd service can also be used as a WINS server or WINS proxy.
Microsoft has produced an implementation of the NetBIOS Name Service (NBNS) called Windows Internet Name Service (WINS). The use of WINS is described in the Microsoft article:
Within Microsoft networks, NetBIOS Name resolution can also make use of the traditional hosts file and the Domain Name System (DNS). For this mechanism to work NetBIOS names need to be the same as the unqualified TPC/IP host name. The implication of this is that the NetBIOS names will also conform to the constraints of the DNS name space (i.e. names can only consist of letters, digits and the dash / hyphen character - and can not contain other special characters otherwise allowed in NetBIOS names such as the underscore character _ ). Microsoft describe the use of a hosts file and the DNS in the article:
Systems can use a combination of the above services to resolve NetBIOS names to IP addresses for example sequentially searching cache, lmhosts file, nbns service, hosts files and the DNS.
The management of names can be a complex issue. To avoid problems it is important that multiple systems do not attempt to update the same name registration service.
In Microsoft NT 4.0 networks a typical arrangement will be as follows:
Other implementations make use of Dynamic DNS (DDNS) with either a DHCP server or the clients themselves updating the DNS server. In this arrangement provided the NetBIOS names conform to the DNS rules for names and are the same as the unqualified DNS name, the need for a NBNS server (WINS) can be removed.
IPX/SPX are the protocols native to Novell NetWare. Details of these protocols can be found in: Novell's Guide to NetWare LAN Analysis
Novell introduced an implementation of NetBIOS over IPX in 1986. The implementation uses IPX datagrams to carry the NetBIOS Frames protocol described above.
The IPX addressing scheme is compared with the native NetBIOS and other schemes in "Addressing - NetBios names" above. In IPX/SPX networks, a 48 bit address (usually a MAC address) identifies a node on a network and a 32 bit address identifies each network. Thus IPX is a routable protocol requiring relatively little administration which makes it a useful means of implementing NetBIOS.
IPX packets are broadly analogous to IP packets in the TCP/IP suite of protocols; IPX packets provide an unreliable datagram delivery service. The structure of the IPX Header is given below for reference:
The IPX Header
The Destination Socket indicates the service being carried over IPX, some examples and the identifier for NetBIOS are given below:
Microsoft have implemented NetBIOS over the NWLink IPX/SPX compatible transport. (NWLink is a clone of Novell's IPX/SPX). The Microsoft implementation is compatible with Novell's NetBIOS over IPX. Microsoft sometimes refers to NetBIOS over IPX as NBIPX.
| Length | Field | |
|---|---|---|
| 2 | Checksum | |
| 2 | Length | |
| 1 | Transport Control | |
| 1 | Packet Type 0 or 4 for IPX, 20 (0x14) WAN broadcast | |
| 6 | Destination Node Address | |
| 4 | Destination Network Address | |
| 2 | Destination Socket | |
| 6 | Source Node Address | |
| 4 | Source Network Address | |
| 2 | source Socket | |
| n | Data | NBIXP packet |
| Length | Field |
|---|---|
| 1 | NBIPX Connection Control flag |
| 1 | Data Stream type |
| 2 | Source connection id |
| 2 | Destination connection id |
| 2 | Send Sequence number |
| 2 | Total data length |
| 2 | Offset |
| 2 | Data length |
| 2 | Receive Sequence number |
| 2 | Bytes received |
| n | Data |
The MAP/TOP Users Group Technical Report Specification of NetBIOS Interface and Name Service Support by Lower Layer OSI Protocols, Version 1.0, September 27, 1989, is reproduced as an appendix in The Open Group CAE Specification "Protocols for X/Open PC Interworking: SMB, Version 2."
Communications Machinery Corporation has implemented a NetBIOS interface for ISO
protocols.
"Netbios for ISO Networks"
Stephen Thomas
Communication Machinery Corporation
NetBIOS can be carried over PPP (Point-to-Point Protocol). The relevant (draft) RFC is:
| Previous | Contents | Next |