Content

| 6.1 |  | Characteristics of Transport Layer Technologies |
| 6.1.8 |  | NetBIOS and NetBEUI |

NetBIOS and NetBEUI are a pair of protocols that work together to provide easily configured, broadcast-based networking service for computers running the Microsoft Windows family of operating systems. NetBIOS supports the following network services:

- Network name registration and verification
- Session establishment, termination, and management
- Reliable session data transfer (connection-oriented)
- Unreliable datagram data transfer (connectionless)
- Monitoring and management of network interfaces and lower-layer protocols

One of the main advantages of using NetBIOS and NetBEUI is that they are simple to configure. The main failing of NetBIOS is that it uses a broadcast-based non-hierarchical namespace, forcing it to rely on other network layer protocols if used over a routed network.

NetBIOS Names
The NetBIOS name space is 16 bytes long. The first 15 characters are the computer name defined by the user during configuration. The last character is a hexadecimal digit representing the type of data in the NetBIOS name and network service using that data on a given machine. NetBIOS computers advertise this information to show what services they can offer to the remainder of the network. NetBIOS names can also be used to identify a machine as being part of a workgroup or domain. The 16th character is also used to identify a NetBIOS name as being either unique as in a computer or user name, or group such as a Microsoft Windows Workgroup or Domain name.

Figure shows the common suffixes for NetBIOS names and the Microsoft networking services that use them.

NetBIOS in Operation
There are three main stages in the operation of NetBIOS:

- Name registration
- Name discovery
- Name release

When a Windows NT computer starts up, the various services running on the machine register themselves using the unique NetBIOS name of the machine and the appropriate hexadecimal character at the 16th byte position. This process is called NetBIOS name registration and uses either a broadcast to the local network or a unicast to a local NetBIOS name server if one has been configured for the computer.

When one NetBIOS host needs to communicate with another, it needs the NetBIOS name of the remote machine. This name can either be input by the user or can be obtained from a network browse list. The browse list is a list of network names and services available on the network that is maintained by a master browser machine. The browse list is built from the NetBIOS information broadcast during the NetBIOS name registration process during the start up of a machine. This list is maintained by the master browser and is sent to one or more backup browsers in the network.

Opening Network Neighborhood in Windows displays the browse list for the network. Periodically, the NetBIOS host computer contacts the master browser for a list of backup browsers from which one is selected. The host computer then contacts the backup browser, retrieves the browse list, and displays it to the user.

If the client cannot locate a master browser on the network, it initiates a browser election to ensure a master browser and at least one backup browser is elected in the network.

The computer browser service only supplies NetBIOS name information. The NetBIOS name discovery process is what occurs when a NetBIOS name needs to be resolved to a lower-level network address. On a local network, this process is completed using either broadcasts to the local network or using a unicast message to a NetBIOS name server if present. The NetBIOS name resolution process is discussed later in this section

When an application or networking service on a host is stopped, the NetBIOS name for that service on that host is available for use by another host. This process is called “NetBIOS Name Release” and is the process that is used to remove services from the network when a network host is shut down.

NetBIOS Name Discovery and Resolution
The operation of NetBIOS-based networks is dependent on resolving NetBIOS names to lower-layer addresses. Because resolving names to addresses is so important, Windows computers use the following process to efficiently check up to six sources of information when attempting to connect to another computer:

1. Check the local NetBIOS name cache
2. Contact a NetBIOS name server
3. Broadcast the name resolution request locally
4. Check the locally stored LMHOSTS file (Windows only)
5. Check the locally stored HOSTS file (Windows only)
6. Contact a Domain Name System server (Windows only)

1. Windows computers maintain a local cache of recently resolved NetBIOS names. This speeds up resolution of names for computers that are connected to regularly.
2. A NetBIOS Name Server (NBNS), normally a Microsoft Windows NT server running the Windows Internet Name Service (WINS) service, maintains name and address information for all computers on the network. Windows computers configured to use a NBNS server do a number of things during startup and shutdown.

> During startup, the client computer requests its own name from the name server to check that no other computer on the network has the same computer name. Recall that NetBIOS names must be unique on the network. If the client computer is already registered in the network, the name address currently being used by the client computer is returned. If the client computer is new to the network, the server returns a message indicating that the requested information is not found, and the client computer registers its own name, address, and services provided in the WINS database. This information remains in the database until the machine is shut down when the client computer requests its registration be released from the database.

3. If the NBNS does not contain name resolution information for the requested machine name, the Windows client sends a local broadcast in an attempt to contact the remote host directly. If there is no response, the Windows computer checks locally stored files.
4. Administrators of Windows computers can configure them with files containing hard-coded name-to-address resolution information. The first of these files is called LMHOSTS (LAN manager hosts) and is a remnant of older implementations of Windows networking.
5. If a suitable entry is not found in the LMHOSTS file, another locally stored file called HOSTS is checked. The HOSTS file is similar to the LMHOSTS file and is a remnant of older implementations of TCP/IP networking.
6. If both of these local files have not been configured with a hard-coded resolution of the desired NetBIOS name and address, and the Windows client is configured to use a DNS server, the DNS server is queried.

NetBIOS and Other Network Layer Protocols
By default, NetBIOS uses the NetBEUI Frame (NBF) protocol at the lower layers of the OSI model for network communications. NetBEUI has the advantage of being very simple to configure, making it highly suitable to small networks unlikely to have a full-time administrator. The main limitation of NetBEUI is that it is broadcast-based and cannot operate over routed networks. To work on a larger scale, NetBIOS must replace NetBEUI with either the IPX/SPX or TCP/IP protocol suites at the network layer of the OSI model. The TCP/IP protocol suite is most commonly used.

When NetBIOS interfaces with the TCP/IP protocol stack, it creates the NetBIOS over TCP/IP (NetBT) protocol. This is slightly misleading, because NetBIOS actually interfaces with UDP, not TCP, at the transport layer of the TCP/IP stack, using the NetBIOS Data Protocol to form NetBT. Recall that NetBIOS provides connection and session management at higher layers in the OSI model. This means NetBIOS does not need to rely on TCP for these functions and is able to use the more bandwidth-efficient UDP at transport layer.

NetBIOS Node Type
Recall that NetBIOS is broadcast-based, but TCP/IP is primarily unicast-based. This means that the behavior of the NetBIOS name resolution process over TCP/IP can be configured depending on the size and nature of the network. Misconfiguration of the NetBIOS node type is a common cause of network problems at the transport layer. The behavior of NetBIOS nodes over TCP can be configured as one of four options:

- B-node (Broadcast node)
- P-node (Peer-to-peer node)
- M-node (Mixed node)
- H-node (Hybrid node)

NetBIOS hosts configured as NetBIOS broadcast nodes use only UDP datagram broadcasts for NetBIOS name registration and resolution. In large networks, this has the negative impact of increasing the load on the network. By default, routers contain packets generated by NetBIOS name registration and resolution from broadcast nodes. This means that NetBIOS B-node operation is not suitable where resources need to be accessed across a router.

Peer-to-peer NetBIOS hosts do not use broadcasts. These hosts rely on having a NetBIOS name server configured to support the operation of NetBIOS name registration and resolution activities. Although this enabled NetBIOS computers to communicate across routers, it makes the network completely reliant on the operation of the NetBIOS name server. If the NetBIOS name server were to fail, the NetBIOS clients would not be able to communicate with each other because they could not broadcast to locate each other.

Computers with mixed node configuration use both B-node and P-node operation for NetBIOS name registration and resolution. The default mode of operation for a mixed node host is broadcast. Therefore, if a broadcast fails to return a positive response, the host reverts to peer-to-peer operation. This enables a computer to locate resources on a local network easily and to use a NetBIOS name server if a required resource is not located on the local network segment.

NetBIOS hosts configured as hybrid node clients also use both peer-to-peer and broadcast operation for NetBIOS name registration and resolution. Unlike Mixed nodes, Hybrid nodes default to using peer-to-peer and revert to using broadcast when peer-to-peer fails to return a positive response.