2.1 Emulating "NetBIOS LANs"At this point, we hit an interesting twist in the terminology. NetBIOS is a driver that presents an API; it is neither a protocol nor a topology. The API does, however, make a number of assumptions about the workings of the underlying network, and it presents some quirky restrictions. The terms "NetBIOS Network" and "NetBIOS LAN" are commonly used to identify the network architecture that is, essentially , defined by the NetBIOS API. RFCs 1001 and 1002 list three basic services that must be supported in order to implement NetBIOS LAN emulation. These are:
The Name Service is used to map NetBIOS names (addresses) to IP addresses in the underlying IP network. The Datagram Service provides for the delivery of NetBIOS datagrams via UDP. Finally, the Session Service is used to establish and maintain point-to-point, connection-oriented NetBIOS sessions over TCP. 2.1.1 The NetBIOS Name ServiceThe NetBIOS LAN architecture is very simple. No routers, no switches just a bunch of nodes connected to a (virtual) wire. Unlike IP, there is no need for separate hardware addresses, network addresses, or even port numbers . Instead, the communications endpoints are identified by 16-byte strings known as "NetBIOS names." NetBIOS addressing is dynamic. Applications may add names as needed and remove those names when they are finished. Each node on the LAN will also have a default name, known as the Machine Name or the Workstation Service Name , which is typically added when NetBIOS starts. The process of adding a name is called registration . There are two kinds of names that can be registered: unique and group . Group names may be shared by multiple clients , thus providing a mechanism for multicast. In contrast, unique names may only be used by one client per LAN. Keep in mind, though, that these are virtual LANs which may actually be spread out across different subnets in a routed IP internetwork. Figure 2.2. Group namesIn addition to their Machine Names, some of the nodes on this IP LAN have registered the group name Lindisfarne . Nodes Mick and Ringo are not members of the group Lindisfarne .
The Name Service is supposed to keep track of all the NetBIOS names in use within the virtual LAN and ensure that messages sent to a given NetBIOS name are directed to the correct underlying IP address. It does this in two ways: On an IP LAN
Figure 2.3. B mode name resolutionNode Chad wishes to contact node Eadfrith . Since the underlying transport is IP, Chad must first discover the IP address of Eadfrith . Chad sends a broadcast name query to all nodes on the local segment, asking Eadfrith to respond. All other nodes should ignore the request.
Over a routed Internet
The Network Administrator chooses a machine to be the N et B IOS N ame S erver (NBNS, aka WINS Server [1] ). Typically this will be a Unix host running Samba, or a Windows NT or W2K server. In order to use the NBNS, all of the nodes that are participating in the virtual NetBIOS LAN must be given the server's IP address. This can be done by entering the address in the client's NetBIOS configuration or, on Windows systems, via DHCP.
NBT client nodes send NetBIOS name registrations and queries directly to the NBNS, which maintains a central database of all registered names in the virtual LAN. This is known as "P mode" (point-to-point) name resolution, and its participants are referred to as "P nodes." Figure 2.4. P mode name resolution
These are the two basic modes of NetBIOS name resolution over NBT. There are, of course, others. The RFCs describe "M mode" (mixed mode) which combines characteristics of P and B modes. "H mode" (hybrid mode) was introduced later; it is similar to M mode except for the order in which B and P mode behavior is applied. The Name Service runs on UDP port 137. According to the RFCs the use of TCP port 137 can be negotiated for some queries, though few (if any) implementations actually support this. 2.1.2 The NetBIOS Datagram ServiceIn the IP world, TCP provides connection-oriented sessions in which packets are acknowledged , put in order, and retransmitted if lost. This creates the illusion of a continuous, sequential data stream from one end to the other. In contrast, UDP datagrams are simply sent. Thus, UDP requires less overhead, but it is less reliable than TCP. NetBIOS also provides connection-oriented (session) and connectionless (datagram) communications. Naturally, NBT maps NetBIOS sessions to TCP and NetBIOS datagrams to UDP. The Datagram Distribution Service is the NBT service that handles NetBIOS datagram transport. It runs on UDP port 138, and can handle unicast (also known as "specific"), multicast (group), and broadcast NetBIOS datagrams. Unicast (specific)
Multicast (group) and broadcast
The Datagram Service is probably the second least well understood aspect of NBT, most likely because its correct implementation isn't critical to filesharing. Many implementations get it wrong, and there is much debate over the value of getting it right. 2.1.3 The NetBIOS Session ServiceThe Session Service is the traditional transport for SMB, and this is our primary reason for caring about NetBIOS at all. The Session Service runs on TCP port 139. [2] There is no particular mechanism for multicast or broadcast because each session is, by definition, a one-to-one connection. The RFCs do, however, briefly discuss what might happen if a session setup request were sent to a group name (see RFC 1001, Section 16.1.1.2).
We will get to the details of session creation, use, and closure when we discuss Session Service implementation. Weirdness Alert
|