Introduction: CIFS from Eight Miles High
0.1 First Impressions
First impressions are important. The handshake, the smile, here's our brochure, would you like a cup of tea?
Microsoft's Windows family of operating systems makes good first impressions. There's a pleasant sound at start-up, all of the basics are represented by simple icons, and everything else is available through a neatly categorized menu.
As the relationship progresses, however, it becomes clear that there is a lot going on beneath the candy -coated surface. This is particularly true of the CIFS protocol suite. The Network Neighborhood icon that appears on the Windows desktop hides a great deal of gear-churning and behind-the-scenes fussing.
The large installed base of Microsoft's Windows products has granted de facto standard status to CIFS. Unfortunately, implementation documentation and detailed protocol specifications are scarce , incomplete, and inconsistent. This is a problem for network administrators, third-party CIFS implementors, and anyone else who wants to know more about the ingredients than you can read on the bottom of the box.
Despite the dearth of good under-the-hood documentation, there are several non-Windows CIFS products. Some of these are based on older versions of Microsoft's own software, but the majority were created by studying the few available references and reverse-engineering to fill in the gaps.
0.2 What is CIFS?
CIFS is a network filesystem plus a set of auxiliary services supported by a bunch of underlying protocols. Any and all of these various bits have been called CIFS, which leaves us with a somewhat muddy definition. To make things easier, we'll start by saying that CIFS is "Microsoft's way of doing network file sharing," and work out the details as we go on.
The name "CIFS," of course, is an acronym. It stands for C ommon I nternet F ile S ystem, a title which deserves a bit of dissection.
0.2.1 A Recipe for Protocol Soup
The filesharing protocol at the heart of CIFS is an updated version of the venerable S erver M essage B lock (SMB) protocol, which dates back to the mid-1980s. The new name first appeared around 1996/97 when Microsoft submitted draft CIFS specifications to the I nternet E ngineering T ask F orce (IETF). Those drafts have since expired , and more recent documentation made available by Microsoft comes encumbered with confusing (and pointless) licensing restrictions.
The SMB protocol was originally developed to run over NetBIOS ( Net work B asic I nput O utput S ystem) LANs. This is a nasty little skeleton in the CIFS closet. Until W2K, NetBIOS support was required for SMB transport. The machine and service names visible in the Windows "Network Neighborhood" are, basically, NetBIOS addresses.
With Windows 3.11 (Windows for Workgroups), Microsoft introduced a service announcement and location system called the Browse Service. This service maintains the list of available file and print services that is presented via the Network Neighborhood (named "My Network Places" in newer Windows products). Also with Windows 3.11 Microsoft introduced the "workgroup" concept. Workgroups simplified network management by organizing servers and services into administrative groups. Microsoft expanded upon the workgroup concept under Windows NT to create NT Domains. 
As if that were not enough, there are also several SMB "dialects." These roughly correspond to major OS product releases or updates from Microsoft, and each adds extensions to the core SMB protocol. In their IETF CIFS draft, Microsoft presented an SMB dialect that was independent of NetBIOS, and W2K does include such a beast . As part of the split with NetBIOS, W2K also offers new name resolution, service announcement, authentication, and authorization mechanismsall based, more or less, upon Internet standards.
Don't worry. Like most complex problems, this can all be understood by breaking it down into little pieces and studying each one in turn . The whole is not so terrible once you understand the parts .