Misplaced Pages

Revision as of 15:24, 6 September 2005

NetBIOS is an acronym for Network Basic Input/Output System. It generally refers to a programming API for local network communication.

History

NetBIOS is not a networking protocol but an application programming interface, co-developed by IBM and Sytec for the so-dubbed PC-Network in the early 1980s. Although only published through a technical reference book from IBM, the protocol's API became a de-facto standard.

As PC-Network hardware is no longer used, having been replaced by TokenRing and Ethernet networks, the NetBIOS protocol might not be needed anymore. However, because a lot of software was written for NetBIOS's API, it has since been adapted to work over various other protocols such as IPX/SPX and TCP/IP.

NetBIOS is available over several transports: the first TokenRing and Ethernet protocols that NetBIOS was made available over is called NETBEUI, and NETBEUI is a MAC layer protocol. NetBIOS was still heavily used until the release of Microsoft Windows 98. As NETBEUI is not routable, it was of little value in LAN and WAN environments, so NetBIOS had to be adapted (proxied) over new transports, such as TCP/IP and IPX/SPX. NetBIOS over TCP/IP is referred to as NBT and has been standardized by IBM in RFCs 1001 and 1002. NBT attempts to provide a NetBIOS-based PC-Network LAN emulation over a routed IP-based network. NBT made its first major world-wide debut in Microsoft Windows for Workgroups. Since Windows 2000, NBT has become the preferred NetBIOS transport.

NetBIOS by itself is not routable because it is by itself not a transport: NetBIOS relies on the underlying transport that carries it (NETBEUI, TCP/IP, DECNet 3.0, IPX/SPX) to perform the routing - if the transport protocol in fact has any. The relationship between these protocols is best explained like this: "NetBIOS is to NETBEUI as TCP/IP-plus-UDP/IP-plus-DHCP-plus-Dynamic-DNS are to Ethernet".

NetBIOS is (by virtually everyone from Microsoft's own employees through to the highest well-paid experienced network administrators with 20 years experience) frequently confused with, mistaken for, and blamed as being synonymous with various long-suffering protocols including, but not limited to, NETBEUI, NBT, SMB, CIFS, DCE/RPC, MSRPC, the Network Neighbourhood suite of protocols, the NT 3.5, 3.51 and 4.0 Domain Protocols (which includes but is not limited to the NT Domain Login, NT Server Administrative Services, and NT Spools Print Services) to name but a few.

It therefore comes as no big surprise that NetBIOS is on most people's hit-list. NetBIOS is, however, extremely sophisticated, and some argue that it still does not yet have a modern parallel to replace it.

Overview

NetBIOS, whatever the adaptation, provides three distinct services:

• Name service: name registration and resolution (equivalent to a combined DHCP and dynamic DNS)
• Session service: reliable connection-oriented communication (equivalent to TCP and SPX)
• Datagram distribution service: unreliable connectionless communication (equivalent to UDP and IPX)

(Note: SMB, an upper layer, is a service that runs on top of the Session Service and the Datagram service, and is not to be confused as a necessary and integral part of NetBIOS itself)

When NetBIOS was an OSI data link layer protocol, its functions were accessed via the 5Ch interrupt. Messages passed to these functions were formatted according to the NCB (Network Control Block) format.

In order to start Sessions or distribute Datagrams, a program must first register, utilising the Name service, the NetBIOS name (equivalent to IP address and comprising up to fifteen ascii characters) and NetBIOS type (equivalent to a port number but only in the range 0 to 255) that it wishes to receive data on. All NetBIOS services, including the dozen or so that comprise the Network Neighbourhood infrastructure (yes, there are quite literally a dozen: Windows Messaging - those really irritating popups you keep getting - is a NetBIOS service!) absolutely must attempt to register both a Name plus a type, in exactly the same way that you must register with a DHCP server to obtain an IP address, and then you can register ports on that IP address for your TCP and UDP services.

If someone is already utilising the NetBIOS name plus type, it is the responsibility of the Name service, running on the host that owns the name, to send a "Node Conflict" message out to absolutely everyone it can possibly find, including on all other transports.

There is a long-standing bug in Microsoft's NetBIOS stack implementation in Windows NT, that affects Windows NT 3.1, 3.5, 3.51, 4.0 and probably 2000. If you place two network cards in a Windows NT box and bind NetBIOS to both, registration occurs on both networks, but the replies come back to one stack: to the NetBIOS stack it therefore appears that there are two systems attempting to register the same name. NT therefore puts its own name into "Conflict", and consequently, no NetBIOS services can be run.

NetBIOS and NETBEUI were originally intended for use on local networks only. Therefore, NETBEUI, which is at the ethernet layer only, has no support for routing and can only handle a maximum of 72 nodes or named devices, but obviously, NBT (and NetBIOS over IPX/SPX) simply rides on the back of (and is encapsulated in) a TCP/IP or IPX/SPX packet or stream. So, in a correctly deployed TCP/IP or IPX/SPX environment, NetBIOS has no such ethernet-layer-imposed limitation on the number of nodes or devices.

Usage of broadcast is intensive, especially for operations related to the name service, especially in badly-configured environments, and especially where NetBIOS over IPX/SPX is deployed (instead of NBT only).

NBT (NetBIOS over TCP/IP) uses one or more NBNS (NetBIOS Name Server(s)) to span name service over multiple subnets (while broadcast is limited to only one subnet, unless network admins decide, in fits of genuine stupidity, to forward NetBIOS broadcast traffic at the ethernet layer between their switches, as a substitute for not realising that a NBNS should be deployed instead). The NetBIOS Name Service is a sort of broadcast-based dynamic DNS, and a NBNS simply receives exactly the same packets, except unicast (to the well-known NBNS address). The NBNS' role is to reduce broadcast traffic and to span subnets - exactly like a Dynamic DNS server in combination with a DHCP server does on a TCP/IP network. The sorts of problems faced by administrators deploying DHCP server(s) over multiple subnets have very close parallels with the sorts of problems faced by administrators deploying NBNS servers - the only difference being that the Network Neighbourhood, which is a conglomeration of NetBIOS Services, is much more robust and tolerant of mistakes and network administrator ignorance.

The packet formats of the Name Service are identical to DNS. The key differences are the addition of NetBIOS "Node Status" query, dynamic registration and conflict marking packets, that a NBNS is contactable by setting the bit (in DNS packets that is used to indicate "send up to next DNS layer") indicating "recursion desired", and the fact that the DNS "zone" was overloaded with the concept of a NetBIOS "scope". Microsoft's programmers, however, failed to appreciate what the NetBIOS "scope" is actually for - so they ignored it. This makes it impossible to stack NBNS servers in the same way that DNS servers can be stacked right up to the root "zones".

Microsoft's implementation of NBNS is called WINS. Moreover, in order to extend virtual NetBIOS networks across multiple IP subnetworks, the standard also introduced the use of one or more NBDD (NetBIOS Datagram Distribution) server(s), primarily for remote dial-in users to be able to broadcast-send Datagrams onto a LAN, and also to receive LAN-broadcasted Datagrams, without actually being on the LAN. Unfortunately, Microsoft's implementation of NBDD never worked.

A comparison of NBNS and NetBIOS (rfcs 1001 and 1002) and the recent Mobile_IP draft RFCs (e.g. draft-ietf-mobileip-reg-revok-01.txt and rfc2002.txt) provide quite literally concept-for-concept parallels (only the names have changed, basically), with the Mobile IP draft RFCs being (when compared to NBNS in combination with the Microsoft Network Neighbourhood) conceptually incomplete! (At the time of analysis - January 2002 - the Mobile IP draft RFCs had neither a parallel concept for conflict marking nor one for "Node Status").

It is quite a feat of the writers of the Mobile IP draft RFCs to have developed Mobile IP in demonstrably complete ignorance of (i.e. without any reference to) NBT and the Network Neighbourhood, despite the fact that the Network Neighbourhood has been successfully deployed for well over fifteen years, in hundreds of thousands of companies world-wide, and that RFCs 1001 and 1002 are dated 1987 - and yet to have come up with identical concepts and solved exactly the same problems.

NetBIOS (over NETBEUI, TCP/IP and IPX/SPX), and especially the Microsoft Network Neighbourhood, were designed to be extremely robust. In the face of total ignorance on the part of network administrators (if one is used at all), the Name Service operates in combination with the Network Neighbourhood to endeavour to provide an accurate discovery and presentation to users of machines deployed, often without permission, on a LAN. Hence the reason why NetBIOS appears to be so blatantly "chatty", and hence its bad rep.

Proper deployment of a NBNS on a LAN, in combination with configuring a DHCP server to automatically tell client machines where that NBNS server is, along with ruthless culling of unnecessary NETBEUI and IPX/SPX networking stacks from Windows machines, has an immediate and dramatic reduction in the amount of pointless broadcast traffic.

External links

• Implementing CIFS (from the Samba team, published under the Open Publication License)
• NetBIOS specification
• NetBios, NetBEUI, NBF, SMB, CIFS Networking

• Network protocols