TechZone Routable and Non-Routable Network Protocols: NetBIOS was never meant to be used in WAN (Wide Area Network) applications because it has a "non-routable flat namespace". This is just a fancy way of saying that NetBIOS identifies computers by using just a single fifteen character name. Designating computers "by name" is quite practical on a network consisting of relatively few computers. If someone's computer is already named FRED, you can name yours FREDRICK, or FREDDY or FRED2 or FRED_2 or anything else not already in use. But just imagine if every computer in the ENTIRE WORLD were sharing this single "flat" namespace where every name had to be unique. You'd sit around forever just trying to come up with some sort of name that no one else had already nabbed. If you've ever tried to find a good name for yourself in any active forum or popular online service, you already know how difficult that can be. So . . . the FIRST problem with NetBIOS going global is that everyone would have to share NetBIOS's single "space" for names (the Namespace). Now for the second and even bigger problem: Knowing that a computer's name is "FRED" doesn't tell another computer located somewhere else anything about where "FRED" might be located on the network. One computer has no way of determining or discovering the ROUTE from itself to any other computer in the world. That's why NetBIOS is called a "Non-Routable" network protocol. But by comparison, the TCP/IP protocol, which uses those whacky "dotted IP" addresses, allows EXACTLY that! Here's how ... Let's use the analogy of a postal letter being delivered. . . When you drop a letter into the mailbox, it's first taken to your LOCAL post office. The first thing the postmaster checks is the CITY of the address to see whether this letter is addressed locally, or bound for an address that's further away. If the address is local, the letter is just aimed at the proper carrier's route for delivery the next day. If the letter is bound for a different city in the same state, the letter must be sent to the post office for that city. If the letter is addressed to another state, then all of the letters heading for that state will probably be grouped together and sent to the state's central dispatch center, where they will be sent to the post office for the destination city. In other words, the addressing information forms an addressing HIERARCHY which immediately shows the local postmaster what he needs to do in order to ROUTE the letter to its destination. He might be able to handle it locally, but if not he hands it up to the next level in the postal hierarchy for further processing. That's all he needs to worry about. Staying with our postal analogy a bit longer: Imagine that we have levels in the addressing hierarchy of: State, City, Street, HouseNumber. Notice that there are a TON of possible addresses within any one state, fewer within a single city, a manageable number on any one street, and the final house number nails it down to its final delivery destination. Now imagine that we were to change the way postal addresses were written to this: State . City . Street . HouseNumber Get it? Isn't that cool? That's EXACTLY the way the Internet addresses computers the world over: Instead of boundaries like States and Cities, it uses numeric groupings, but the hierarchy is just the same. Just as a neighbor on your street has an address almost exactly like yours — differing only in house number — you'll notice that the IP addresses of computers "near" yours probably differ in only the last dotted number! Thus both the postal system and the Internet employ a hierarchal namespace for addressing! And that's the key to the way the TCP/IP protocol is able to "go Global" whereas NetBIOS, with it's single, simple, computer names (a flat namespace), is destined to forever stay local. (Imagine how much luck you'd have if you were to address a letter by simply writing "Fred" on the envelope!) With this background in place, we're ready to look at the final piece of the puzzle: As we've seen, NetBIOS's simple non-hierarchal "flat" naming system prevents it from handling global addresses. But as we all know, the Internet "happened". So, rather than inventing a completely new (and perhaps more elegant) solution for Windows' Wide Area Networking (WAN), the decision was made to retain the existing NetBIOS by "encapsulating" it within TCP/IP. This would use the global (WAN) TCP/IP protocol as the carrier for the local (LAN) NetBIOS which many millions of machines already understood. The result was "NetBIOS over TCP/IP", NetBT or NBT for short. The term used to describe NetBIOS's encapsulation within TCP/IP is "binding": The NetBIOS protocol is said to be bound to TCP/IP in order to use it as its carrier (as its TRANSPORT). Since TCP/IP can go anywhere, strapping NetBIOS onto the back of TCP/IP allows it to carry the protocol where it was never designed to go. It should be said, however, that this approach was somewhat "unclean" from a theoretical standpoint, and many compromises and "kludges" were required to make it all work in practice. During my research for this site, I stumbled upon a description of this process that you might find illuminating: On this page: http://www.labmed.umn.edu/~john/netbios.html John G. Faughnan of the University of Minnesota writes: NetBIOS is enough to make admirers of Microsoft grimace. It is a twisted version of the Net, where DNS (Domain Name Server) becomes WINS and HOSTS becomes LMHOSTS. Long ago (1983) it was born as a network protocol for the very early IBM PC networks; then it required custom hardware. It mutated into LAN Manager (then OS/2 then Warp then nothing) and Windows for Workgroups NetBEUI. (see also: Microsoft's explanation of NetBIOS) Finally the network layers were gutted, the naming services and application interfaces preserved, a terrible surgery performed, and NetBIOS over TCP/IP was born. This is what many of us live with now. It is not a pretty synthesis. DNS, WINS, HOSTS, LMHOSTS, PNC (primary network controller), domains, workgroups, TCP caching, Browse-Master, ports and routers, Win32 variations, and scopes all interact with one another. The usual symptom of a royal mess is that it's possible to access servers using UNC (enter \\name in the Run box for example), but impossible to browse a network using network neighborhood. Disclaimer: The views and opinions expressed in this page are strictly those of the page author. The contents of this page have not been approved by the University of Minnesota. So, while NetBIOS bound to TCP/IP may not be the ideal or perfect solution, it's the technology chosen and designed by Microsoft, and it defines the networking environment we'll all be using for some time to come. Helping you to make it work for you, rather than against you, is the goal of my work on this site. You should now have a pretty good idea for how NetBIOS and TCP/IP operate, and how NetBIOS relates to TCP/IP. ...