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 has not yet widely replaced IP version 4. 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: RFC 1001 Protocol standard for a NetBIOS service on a TCP/UDP transport: concepts and methods RFC 1002 Protocol standard for a NetBIOS service on a TCP/UDP transport: detailed specifications The protocol standards described in the above RFCs are designed to preserve existing NetBIOS services, utilize existing standards and minimize 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 that 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 that 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 standardized; 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: http://www.samba.org 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 / CIFS 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 dependent. 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: Article ID: Q101927 "The Lmhosts File for TCP/IP in Windows" Article ID: Q102725 "LMHOSTS File Information and Predefined Keywords" Article ID: Q104576 "Embedding Non-printable Characters in LMHOSTS Computer Names" Article ID: Q108295 "TCP/IP Name Resolution" Article ID: Q150800 "Domain Browsing with TCP/IP and LMHOSTS Files" Article ID: Q180094 "How to Write an LMHOSTS File for Domain Validation and Other Name Resolution Issues"

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: Article ID: Q119493 "NetBIOS over TCP/IP Name Resolution and WINS"

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: Article ID: Q142309 "NetBIOS Name Resolution Using DNS and the HOSTS File"

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: A DHCP server will allocate IP addresses to client systems when they boot. Client systems are allocated NetBIOS names at installation time. The names conforms to the DNS rules for names and are the same as the unqualified DNS name. At boot time the client registers it's NetBIOS name and DHCP assigned address with a NBNS server (often a WINS server). The Microsoft DNS server is configured to resolve host names by taking the unqualified DNS name and passing the enquiry to the WINS server. 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.

The latest versions of CIFS can run "natively" over TCP/IP without requiring the "NetBIOS over TCP/IP" layer. In this implementation the NetBIOS layer is removed completely. With the introduction of Windows 2000 and Active Directory, the latest version of CIFS can use traditional fully qualified DNS names to represent nodes on the network.