Misplaced Pages

NetBIOS: Difference between revisions

Article snapshot taken from Wikipedia with creative commons attribution-sharealike license. Give it a read and then ask your questions in the chat. We can research this topic together.
Browse history interactively← Previous editContent deleted Content addedVisualWikitext
Revision as of 21:31, 27 August 2005 edit24.214.30.98 (talk) add link to show netbios info.← Previous edit Latest revision as of 12:26, 4 September 2024 edit undo217.145.83.141 (talk) correcting unclear wordingTag: Visual edit 
(467 intermediate revisions by more than 100 users not shown)
Line 1: Line 1:
{{Short description|API allowing applications on separate computers to communicate over LAN via the session layer}}
'''NetBIOS''' is an acronym for '''Network Basic Input/Output System'''. It generally refers to a programming ] for ] communication.
{{Redirect2|NetBEUI|NetBIOS Enhanced User Interface|specifically the protocol available in Microsoft Windows|NetBIOS Frames|details|#NetBEUI}}
{{Redirect|Network Basic Input/Output System|the Network I/O System|NIOS (Digital Research)}}
<!-- The term "NetBEUI" is unusually problematic and actually does redirect here. Please, do not remove the hatnote without discussion. -->
{{Multiple issues|
{{more footnotes|date=August 2012}}
{{Technical|date=September 2010}}
}}


{{Use dmy dates|date=July 2020}}
== History ==


'''NetBIOS''' ({{IPAc-en|ˈ|n|ɛ|t|b|aɪ|ɒ|s}}) is an acronym for '''Network Basic Input/Output System'''. It provides services related to the ] of the ] allowing applications on separate computers to communicate over a ]. As strictly an ], NetBIOS is not a ]. ]s of the 1980s (DOS and Novell Netware primarily) ran NetBIOS over ] and ] using the ] (NBF) and ] (NBX) protocols, respectively. In modern networks, NetBIOS normally runs over ] via the ] (NBT) protocol. NetBIOS is also used for identifying system names in TCP/IP (Windows).
NetBIOS is not a ] but an ], co-developed by ] and Sytec for the so-dubbed ] in the early 1980s. Although only published through a technical reference book from IBM, the protocol's API became a de-facto ].


==History and terminology==
As PC-Network hardware is no longer used, having been replaced by ] and ] 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 ] and ].
NetBIOS is an operating system-level API that allows applications on computers to communicate with one another over a ] (LAN). The API was created in 1983 by ]. for software communication over ] LAN technology.<ref name="barrie"/> On ], as an API alone, NetBIOS relied on proprietary Sytek networking protocols for communication over the wire.<ref>{{Cite web |title=10. Assessing Windows Networking Services - Network Security Assessment, 2nd Edition |url=https://www.oreilly.com/library/view/network-security-assessment/9780596510305/ch10.html |access-date=2023-04-20 |website=www.oreilly.com |language=en |archive-date=20 April 2023 |archive-url=https://web.archive.org/web/20230420121049/https://www.oreilly.com/library/view/network-security-assessment/9780596510305/ch10.html |url-status=live }}</ref>


{{anchor|NetBEUI}}In 1985, IBM went forward with the ] network scheme and produced an ] of Sytek's NetBIOS API to allow NetBIOS-aware applications from the PC-Network era to work over IBM's new Token Ring hardware. This IBM emulator, named NetBIOS Extended User Interface (NetBEUI), expanded the base NetBIOS API created by Sytek with, among other things, the ability to deal with the greater node capacity of Token Ring. A new networking protocol, ], was simultaneously produced by IBM to allow its NetBEUI API (their enhanced NetBIOS API) to provide its services over Token Ring – specifically, at the ] ] layer.
NetBIOS is available over several transports: the first TokenRing and Ethernet protocols that NetBIOS was made available over is called ], and NETBEUI is a MAC layer protocol. NetBIOS was still heavily used until the release of ] 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 ] and has been standardized by IBM in ]s 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.


In 1985, ] created its own implementation of the NetBIOS API for its ] networking technology. As in the case of IBM's Token Ring, the services of Microsoft's NetBIOS implementation were provided over the IEEE 802.2 Logical Link Control layer by the NBF protocol.<ref>{{Cite web |title=Getaway hardware for protocols |url=https://www.networking-hardware.com/juniper/service-gateway |access-date=2023-04-20 |website=www.networking-hardware.com |archive-date=26 March 2023 |archive-url=https://web.archive.org/web/20230326062716/https://www.networking-hardware.com/juniper/service-gateway |url-status=live }}</ref> However, the MS-Net was only delivered to ]s, and it was actually not a complete product, nor was it ready to communicate on the network in the form it was distributed. It lacked any implementation of ] Layers 1 to 4 (], ], ] and ] Layers) and an OEM was expected to provide these implementations (in the form of a NetBIOS part) to make its version of MS-Net a complete and ready to use product. MS-Net accessed the network through the Microsoft's own variant of NetBIOS, which was split into two parts - the lower level part that OEMs had to provide implemented the NetBIOS calls that depended on layers 1-4, while the higher level part, provided by Microsoft, was hardware- and protocol-independent. This NetBIOS implementation supported the full NetBIOS API, but was called by invoking ] interrupt 0x2A, instead of IBM's standard interrupt 0x5C. The reliance on OEMs to implement parts of NetBIOS had the unfortunate side effect that different OEM versions of MS-Net and NetBIOS generally weren't able to communicate with one another. <ref>{{Cite web |title=Early Microsoft Networks {{!}} OS/2 Museum |url=http://www.os2museum.com/wp/early-microsoft-networks/ |access-date=2024-09-04 |language=en-US}}</ref>
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".


In 1986, ] released Advanced ] 2.0 featuring the company's own emulation of the NetBIOS API. Its services were encapsulated within NetWare's ] protocol using the ] (NBX) protocol.
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.


In 1987, a method of encapsulating NetBIOS in ] and ] packets, ] (NBT), was published. It was described in RFC 1001 ("Protocol Standard for a NetBIOS Service on a TCP/UDP Transport: Concepts and Methods") and RFC 1002 ("Protocol Standard for a NetBIOS Service on a TCP/UDP Transport: Detailed Specifications"). The NBT protocol was developed in order to "allow an implementation to be built on virtually any type of system where the TCP/IP protocol suite is available," and to "allow NetBIOS interoperation in the Internet."
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.


After the ] computer hit the market in 1987, IBM released the PC LAN Support Program, which included a driver offering the NetBIOS API.
== Overview ==


There is some confusion between the names NetBIOS and NetBEUI. NetBEUI originated strictly as the ] for IBM's enhanced 1985 NetBIOS emulator for Token Ring. The name NetBEUI should have died there, considering that at the time, the NetBIOS implementations by other companies were known simply as NetBIOS regardless of whether they incorporated the API extensions found in Token Ring's emulator. For MS-Net, however, Microsoft elected to name its implementation of the NBF protocol "NetBEUI" – naming its implementation of the transport protocol after IBM's enhanced version of the API.{{cn|date=June 2023|reason=A source needed to support the alleged controversy that the protocol implemented by NetBIOS emulator over 802.2 would be different between Token Ring and Ethernet networks.}} Consequently Microsoft file and printer sharing over ] often continues to be called NetBEUI, with the name NetBIOS commonly used only in reference to file and printer sharing over ]. More accurately, the former is ] (NBF), and the latter is ] (NBT).
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 ] communication (equivalent to UDP and IPX)


Since its original publication in a technical reference book from IBM, the NetBIOS API specification has become a ] in the industry despite originally supporting a maximum of only 80 PCs in a LAN. This limitation was generally overcome industry-wide through the transition from NBF to NBT, under which, for example, Microsoft was able to switch to ] (DNS) for resolution of NetBIOS ]s, having formerly used the LAN segment-compartmentalized NBF protocol itself to resolve such names in Windows ].<ref name="barrie"/>
(Note: ], 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)


==Services==
When NetBIOS was an ] ] protocol, its functions were accessed via the 5Ch ]. Messages passed to these functions were formatted according to the ] (Network Control Block) format.
NetBIOS provides three distinct services:
*Name service (NetBIOS-NS) for name registration and ].
*] distribution service (NetBIOS-DGM) for connectionless communication.
*] service (NetBIOS-SSN) for ].


(Note: ], 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. It can now run atop TCP with a small adaptation layer that adds a length field to each SMB message; this is necessary because TCP only provides a byte-stream service with no notion of message boundaries.)
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.


===Name service===
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.
In order to start sessions or distribute datagrams, an application must register its NetBIOS name using the name service. NetBIOS names are 16 octets in length and vary based on the particular implementation. Frequently, the 16th octet, called the NetBIOS Suffix, designates the type of resource, and can be used to tell other applications what type of services the system offers.{{cn|date=June 2023|reason=Unclear from text what is meant by "octets". Possibly confuses octets with bytes.}} In ], the name service operates on UDP port 137 (TCP port 137 can also be used, but rarely is).


The name service primitives offered by NetBIOS are:
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.
*Add name – registers a NetBIOS name.
*Add group name – registers a NetBIOS "group" name.
*Delete name – un-registers a NetBIOS name or group name.
*Find name – looks up a NetBIOS name on the network.


] are not supported by the NetBIOS name resolution protocol.<ref>{{cite web |title=: WINS Management Protocol |url=https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-wpo/26b6d27b-7470-4a0d-bcfc-88670c6c50d4 |website=learn.microsoft.com |language=en-us |date=14 February 2019 |quote=Because the NetBIOS protocol, defined in , does not support the mapping between NetBIOS names and IPv6 addresses, the Remote Administrative Interface: WINS protocol applies only to IPv4 addresses. It does not apply to IPv6 addresses. |access-date=17 June 2023 |archive-date=17 June 2023 |archive-url=https://web.archive.org/web/20230617123311/https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-wpo/26b6d27b-7470-4a0d-bcfc-88670c6c50d4 |url-status=live }}</ref>
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 ] 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.


===Datagram distribution service===
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).
Datagram mode is ]; the application is responsible for error detection and recovery. In ], the datagram service runs on UDP port 138.


The datagram service primitives offered by NetBIOS are:
NBT (NetBIOS over TCP/IP) uses one or more ] (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.
*Send Datagram – send a datagram to a remote NetBIOS name.
*Send Broadcast Datagram – send a datagram to all NetBIOS names on the network.
*Receive Datagram – wait for a packet to arrive from a Send Datagram operation.
*Receive Broadcast Datagram – wait for a packet to arrive from a Send Broadcast Datagram operation.


===Session service===
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".
Session mode lets two computers establish a connection, allows messages to span multiple packets, and provides error detection and recovery. In ], the session service runs on TCP port 139.


The session service primitives offered by NetBIOS are:
Microsoft's implementation of NBNS is called ]. Moreover, in order to extend virtual NetBIOS networks across multiple IP subnetworks, the standard also introduced the use of one or more ] (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.
*Call – opens a session to a remote NetBIOS name.
*Listen – listen for attempts to open a session to a NetBIOS name.
*Hang Up – close a session.
*Send – sends a packet to the computer on the other end of a session.
*Send No Ack – like Send, but doesn't require an acknowledgment.
*Receive – wait for a packet to arrive from a Send on the other end of a session.


In the original protocol used to implement NetBIOS services on PC-Network, to establish a session, the initiating computer sends an Open request which is answered by an Open acknowledgment. The computer that started the session will then send a Session Request packet which will prompt either a Session Accept or Session Reject packet.
A comparison of NBNS and NetBIOS (rfcs 1001 and 1002) and the recent ] 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").


During an established session, each transmitted packet is answered by either a positive-acknowledgment (ACK) or negative-acknowledgment (NAK) response. A NAK will prompt retransmission of the data. Sessions are closed by the non-initiating computer by sending a close request. The computer that started the session will reply with a close response which prompts the final session closed packet.
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 name vs Internet host name==
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 rap.
When NetBIOS is run in conjunction with ]s (e.g., NBT), each computer may have multiple names: one or more NetBIOS name service names and one or more Internet host names.


===NetBIOS name===
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.
The NetBIOS name is 16 ASCII characters, however Microsoft limits the host name to 15 characters and reserves the 16th character as a NetBIOS Suffix.<ref name="MS"/> This suffix describes the service or name record type such as host record, master browser record, or domain controller record or other services. The host name (or short host name) is specified when Windows networking is installed/configured, the suffixes registered are determined by the individual services supplied by the host. In order to connect to a computer running TCP/IP via its NetBIOS name, the name must be resolved to a ]. Today this is usually an ] (the NetBIOS name to IP address resolution is often done by either broadcasts or a ] Server – NetBIOS Name Server). A computer's NetBIOS name is often the same as that computer's host name (see below), although truncated to 15 characters, but it may also be completely different.

NetBIOS names are a sequence of alphanumeric characters. The following characters are explicitly not permitted: <samp>\/:*?"<>|</samp>. Since Windows 2000, NetBIOS names also had to comply with restrictions on DNS names: they cannot consist entirely of digits, and the hyphen ("-") or full-stop (".") characters may not appear as the first or last character. Since Windows 2000, Microsoft has advised against including any full-stop (".") characters in NetBIOS names, such that applications can use the presence of a full-stop to distinguish domain names from NetBIOS names.<ref name="MS"/>

The Windows ] file provides a NetBIOS name resolution method that can be used for small networks that do not use a WINS server.

===Internet host name===
A Windows machine's NetBIOS name is not to be confused with the computer's Internet host name (assuming that the computer is also an Internet host in addition to being a NetBIOS node, which need not necessarily be the case). Generally a computer running Internet protocols (whether it is a Windows machine or not) usually has a host name (also sometimes called a machine name). Originally these names were stored in and provided by a ] but today most such names are part of the hierarchical ] (DNS).

Generally the host name of a Windows computer is based on the NetBIOS name plus the Primary DNS Suffix, which are both set in the System Properties dialog box. There may also be connection-specific suffixes which can be viewed or changed on the DNS tab in Control Panel → Network → TCP/IP → Advanced Properties. Host names are used by ] such as ], ], ]s, etc. To connect to a computer running the TCP/IP protocol using its name, the host name must be resolved into an ], typically by a DNS server. (It is also possible to operate many TCP/IP-based applications, including the three listed above, using only IP addresses, but this is not the norm.)

==Node types==
Under Windows, the '''node type''' of a networked ] relates to the way it resolves NetBIOS names to ]es. This assumes that there are any IP addresses for the NetBIOS nodes, which is assured only when NetBIOS operates over NBT; thus, node types are not a property of NetBIOS per se but of interaction between NetBIOS and TCP/IP in the Windows OS environment. There are four node types.
*B-node: 0x01 Broadcast
*P-node: 0x02 Peer (WINS only)
*M-node: 0x04 Mixed (broadcast, then WINS)
*H-node: 0x08 Hybrid (WINS, then broadcast)

The node type in use is displayed by opening a ] and typing ''ipconfig /all''.
A ] computer registry may also be configured in such a way as to display "unknown" for the node type.

==NetBIOS Suffixes==
The NetBIOS Suffix, alternately called the NetBIOS End Character (endchar), is the 16th character of a NetBIOS name and indicates service type for the registered name. The number of record types is limited to 255; some commonly used values are:

For unique names:
*00: Workstation Service (workstation name)
*03: ]
*06: ]
*20: ] (also called Host Record)
*21: ] client
*1B: ] Master ] – Primary Domain Controller for a domain
*1D: Master Browser

For group names:
*00: Workstation Service (workgroup/domain name)
*1C: ] for a domain (group record with up to 25 IP addresses)
*1E: Browser Service Elections

== Protocol stack ==
The following table shows a brief history of NetBIOS and its related protocols. ] was the main protocol that used NetBIOS. SMB enables Windows File and Printer Sharing.
{| class="wikitable"
|+
|7
|]
| rowspan="2" |
|], ], ]
| rowspan="2" |SMB
| rowspan="2" |SMB
| rowspan="2" |SMB
| rowspan="3" |SMB
| rowspan="3" |SMB
|-
|6
|]
|]
|-
|5
|]
| rowspan="4" |NetBIOS (The original "Network Basic Input/Output System")
| colspan="2" rowspan="3" |NetBIOS (], incorrectly labeled as "NetBEUI" in Windows)
|NetBIOS (NetBIOS over IPX/SPX)
|NetBIOS (])
|-
|4
|]
|]
|]/]
|]/]
|] (over ])
|-
|3
|]
|]
|]
|]
|]
|-
|2
|]
| colspan="2" |] on ], ]
|Any link that carries IPX
|Any link that carries IP
|Any link that carries IP
|Any link that carries IP
|-
|1
|]
|]
| colspan="2" |], ]
|
|
|
|
|-
| colspan="2" |First supported
|
| colspan="2" |Windows for Workgroups 3.1
|Windows for Workgroups 3.1
|Windows NT 3.5
|Windows 2000
|Windows 11 (Server side requires Windows Server 2022 Datacenter: Azure Edition)
|-
| colspan="2" |Last supported
|
| colspan="2" |Windows XP (requires manual install)
|Windows XP
|
|
|
|}

==See also==
*] (NBT)
*] (NBF)
*] (SMB)

==References==
{{Reflist|refs=
<ref name="barrie">{{Cite book |title=Networking Bible |url=https://archive.org/details/networkingbible0000sosi |url-access=limited |author-last=Sosinsky |author-first=Barrie |publisher=] |date=2009 |isbn=9780470543429 |pages=}}</ref>
<ref name="MS">{{cite web |title=Naming conventions in Active Directory for computers, domains, sites, and OUs |publisher=] |url=https://support.microsoft.com/en-us/help/909264/naming-conventions-in-active-directory-for-computers-domains-sites-and |access-date=2017-12-19 |archive-date=22 December 2017 |archive-url=https://web.archive.org/web/20171222054350/https://support.microsoft.com/en-us/help/909264/naming-conventions-in-active-directory-for-computers-domains-sites-and |url-status=live }}</ref>
}}

==Further reading==
* Haugdahl, J. Scott (1990). ''Inside NetBIOS''. Architecture Technology Corp. {{ISBN|99914-57-34-8}}
* Silberschatz, Abraham; Galvin, Peter Baer; Gagne, Greg (2004). ''Operating System Concepts''. (7th Ed.). John Wiley & Sons. {{ISBN|0-471-69466-5}}
* Meyers, Michael (2004). "Managing and Troubleshooting Networks". McGraw-Hill. {{ISBN|978-0-07-225665-9}}
* Tamara Dean. ''Network+ Guide to Networks'', pg. 206 (NetBEUI)


==External links== ==External links==
*
* (from the ] team, published under the ]) * (from the ] team, published under the ])
* *
*
*
*
* Shows possible NETBIOS shares, IP Address, ISP and other hidden info on your computer.
* – Microsoft Knowledge Base article describing list of NetBIOS Suffixes.
* .
* {{cite web |url=http://samba.anu.edu.au/cifs/docs/what-is-smb.html |title=Just what is SMB? |author=Richard Sharpe |date=8 October 2002 |access-date=1 January 2012 |archive-url=https://web.archive.org/web/20091202045224/http://samba.anu.edu.au/cifs/docs/what-is-smb.html |archive-date=2 December 2009 |url-status=dead }}


{{Authority control}}
]


{{DEFAULTSORT:Netbios}}
]
]
]
]
]
]
]
]
]

Latest revision as of 12:26, 4 September 2024

API allowing applications on separate computers to communicate over LAN via the session layer "NetBEUI" and "NetBIOS Enhanced User Interface" redirect here. For specifically the protocol available in Microsoft Windows, see NetBIOS Frames. For details, see § NetBEUI. "Network Basic Input/Output System" redirects here. For the Network I/O System, see NIOS (Digital Research).
This article has multiple issues. Please help improve it or discuss these issues on the talk page. (Learn how and when to remove these messages)
This article includes a list of general references, but it lacks sufficient corresponding inline citations. Please help to improve this article by introducing more precise citations. (August 2012) (Learn how and when to remove this message)
This article may be too technical for most readers to understand. Please help improve it to make it understandable to non-experts, without removing the technical details. (September 2010) (Learn how and when to remove this message)
(Learn how and when to remove this message)

NetBIOS (/ˈnɛtbaɪɒs/) is an acronym for Network Basic Input/Output System. It provides services related to the session layer of the OSI model allowing applications on separate computers to communicate over a local area network. As strictly an API, NetBIOS is not a networking protocol. Operating systems of the 1980s (DOS and Novell Netware primarily) ran NetBIOS over IEEE 802.2 and IPX/SPX using the NetBIOS Frames (NBF) and NetBIOS over IPX/SPX (NBX) protocols, respectively. In modern networks, NetBIOS normally runs over TCP/IP via the NetBIOS over TCP/IP (NBT) protocol. NetBIOS is also used for identifying system names in TCP/IP (Windows).

History and terminology

NetBIOS is an operating system-level API that allows applications on computers to communicate with one another over a local area network (LAN). The API was created in 1983 by Sytek Inc. for software communication over IBM PC Network LAN technology. On IBM PC Network, as an API alone, NetBIOS relied on proprietary Sytek networking protocols for communication over the wire.

In 1985, IBM went forward with the Token Ring network scheme and produced an emulator of Sytek's NetBIOS API to allow NetBIOS-aware applications from the PC-Network era to work over IBM's new Token Ring hardware. This IBM emulator, named NetBIOS Extended User Interface (NetBEUI), expanded the base NetBIOS API created by Sytek with, among other things, the ability to deal with the greater node capacity of Token Ring. A new networking protocol, NBF, was simultaneously produced by IBM to allow its NetBEUI API (their enhanced NetBIOS API) to provide its services over Token Ring – specifically, at the IEEE 802.2 Logical Link Control layer.

In 1985, Microsoft created its own implementation of the NetBIOS API for its MS-Net networking technology. As in the case of IBM's Token Ring, the services of Microsoft's NetBIOS implementation were provided over the IEEE 802.2 Logical Link Control layer by the NBF protocol. However, the MS-Net was only delivered to OEMs, and it was actually not a complete product, nor was it ready to communicate on the network in the form it was distributed. It lacked any implementation of OSI Layers 1 to 4 (Physical, Data link, Network and Transport Layers) and an OEM was expected to provide these implementations (in the form of a NetBIOS part) to make its version of MS-Net a complete and ready to use product. MS-Net accessed the network through the Microsoft's own variant of NetBIOS, which was split into two parts - the lower level part that OEMs had to provide implemented the NetBIOS calls that depended on layers 1-4, while the higher level part, provided by Microsoft, was hardware- and protocol-independent. This NetBIOS implementation supported the full NetBIOS API, but was called by invoking x86 interrupt 0x2A, instead of IBM's standard interrupt 0x5C. The reliance on OEMs to implement parts of NetBIOS had the unfortunate side effect that different OEM versions of MS-Net and NetBIOS generally weren't able to communicate with one another.

In 1986, Novell released Advanced Novell NetWare 2.0 featuring the company's own emulation of the NetBIOS API. Its services were encapsulated within NetWare's IPX/SPX protocol using the NetBIOS over IPX/SPX (NBX) protocol.

In 1987, a method of encapsulating NetBIOS in TCP and UDP packets, NetBIOS over TCP/IP (NBT), was published. It was described in RFC 1001 ("Protocol Standard for a NetBIOS Service on a TCP/UDP Transport: Concepts and Methods") and RFC 1002 ("Protocol Standard for a NetBIOS Service on a TCP/UDP Transport: Detailed Specifications"). The NBT protocol was developed in order to "allow an implementation to be built on virtually any type of system where the TCP/IP protocol suite is available," and to "allow NetBIOS interoperation in the Internet."

After the PS/2 computer hit the market in 1987, IBM released the PC LAN Support Program, which included a driver offering the NetBIOS API.

There is some confusion between the names NetBIOS and NetBEUI. NetBEUI originated strictly as the moniker for IBM's enhanced 1985 NetBIOS emulator for Token Ring. The name NetBEUI should have died there, considering that at the time, the NetBIOS implementations by other companies were known simply as NetBIOS regardless of whether they incorporated the API extensions found in Token Ring's emulator. For MS-Net, however, Microsoft elected to name its implementation of the NBF protocol "NetBEUI" – naming its implementation of the transport protocol after IBM's enhanced version of the API. Consequently Microsoft file and printer sharing over Ethernet often continues to be called NetBEUI, with the name NetBIOS commonly used only in reference to file and printer sharing over TCP/IP. More accurately, the former is NetBIOS Frames (NBF), and the latter is NetBIOS over TCP/IP (NBT).

Since its original publication in a technical reference book from IBM, the NetBIOS API specification has become a de facto standard in the industry despite originally supporting a maximum of only 80 PCs in a LAN. This limitation was generally overcome industry-wide through the transition from NBF to NBT, under which, for example, Microsoft was able to switch to Domain Name System (DNS) for resolution of NetBIOS hostnames, having formerly used the LAN segment-compartmentalized NBF protocol itself to resolve such names in Windows client-server networks.

Services

NetBIOS provides three distinct services:

(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. It can now run atop TCP with a small adaptation layer that adds a length field to each SMB message; this is necessary because TCP only provides a byte-stream service with no notion of message boundaries.)

Name service

In order to start sessions or distribute datagrams, an application must register its NetBIOS name using the name service. NetBIOS names are 16 octets in length and vary based on the particular implementation. Frequently, the 16th octet, called the NetBIOS Suffix, designates the type of resource, and can be used to tell other applications what type of services the system offers. In NBT, the name service operates on UDP port 137 (TCP port 137 can also be used, but rarely is).

The name service primitives offered by NetBIOS are:

  • Add name – registers a NetBIOS name.
  • Add group name – registers a NetBIOS "group" name.
  • Delete name – un-registers a NetBIOS name or group name.
  • Find name – looks up a NetBIOS name on the network.

Internet Protocol Version 6 (IPv6) are not supported by the NetBIOS name resolution protocol.

Datagram distribution service

Datagram mode is connectionless; the application is responsible for error detection and recovery. In NBT, the datagram service runs on UDP port 138.

The datagram service primitives offered by NetBIOS are:

  • Send Datagram – send a datagram to a remote NetBIOS name.
  • Send Broadcast Datagram – send a datagram to all NetBIOS names on the network.
  • Receive Datagram – wait for a packet to arrive from a Send Datagram operation.
  • Receive Broadcast Datagram – wait for a packet to arrive from a Send Broadcast Datagram operation.

Session service

Session mode lets two computers establish a connection, allows messages to span multiple packets, and provides error detection and recovery. In NBT, the session service runs on TCP port 139.

The session service primitives offered by NetBIOS are:

  • Call – opens a session to a remote NetBIOS name.
  • Listen – listen for attempts to open a session to a NetBIOS name.
  • Hang Up – close a session.
  • Send – sends a packet to the computer on the other end of a session.
  • Send No Ack – like Send, but doesn't require an acknowledgment.
  • Receive – wait for a packet to arrive from a Send on the other end of a session.

In the original protocol used to implement NetBIOS services on PC-Network, to establish a session, the initiating computer sends an Open request which is answered by an Open acknowledgment. The computer that started the session will then send a Session Request packet which will prompt either a Session Accept or Session Reject packet.

During an established session, each transmitted packet is answered by either a positive-acknowledgment (ACK) or negative-acknowledgment (NAK) response. A NAK will prompt retransmission of the data. Sessions are closed by the non-initiating computer by sending a close request. The computer that started the session will reply with a close response which prompts the final session closed packet.

NetBIOS name vs Internet host name

When NetBIOS is run in conjunction with Internet protocols (e.g., NBT), each computer may have multiple names: one or more NetBIOS name service names and one or more Internet host names.

NetBIOS name

The NetBIOS name is 16 ASCII characters, however Microsoft limits the host name to 15 characters and reserves the 16th character as a NetBIOS Suffix. This suffix describes the service or name record type such as host record, master browser record, or domain controller record or other services. The host name (or short host name) is specified when Windows networking is installed/configured, the suffixes registered are determined by the individual services supplied by the host. In order to connect to a computer running TCP/IP via its NetBIOS name, the name must be resolved to a network address. Today this is usually an IP address (the NetBIOS name to IP address resolution is often done by either broadcasts or a WINS Server – NetBIOS Name Server). A computer's NetBIOS name is often the same as that computer's host name (see below), although truncated to 15 characters, but it may also be completely different.

NetBIOS names are a sequence of alphanumeric characters. The following characters are explicitly not permitted: \/:*?"<>|. Since Windows 2000, NetBIOS names also had to comply with restrictions on DNS names: they cannot consist entirely of digits, and the hyphen ("-") or full-stop (".") characters may not appear as the first or last character. Since Windows 2000, Microsoft has advised against including any full-stop (".") characters in NetBIOS names, such that applications can use the presence of a full-stop to distinguish domain names from NetBIOS names.

The Windows LMHOSTS file provides a NetBIOS name resolution method that can be used for small networks that do not use a WINS server.

Internet host name

A Windows machine's NetBIOS name is not to be confused with the computer's Internet host name (assuming that the computer is also an Internet host in addition to being a NetBIOS node, which need not necessarily be the case). Generally a computer running Internet protocols (whether it is a Windows machine or not) usually has a host name (also sometimes called a machine name). Originally these names were stored in and provided by a hosts file but today most such names are part of the hierarchical Domain Name System (DNS).

Generally the host name of a Windows computer is based on the NetBIOS name plus the Primary DNS Suffix, which are both set in the System Properties dialog box. There may also be connection-specific suffixes which can be viewed or changed on the DNS tab in Control Panel → Network → TCP/IP → Advanced Properties. Host names are used by applications such as telnet, ftp, web browsers, etc. To connect to a computer running the TCP/IP protocol using its name, the host name must be resolved into an IP address, typically by a DNS server. (It is also possible to operate many TCP/IP-based applications, including the three listed above, using only IP addresses, but this is not the norm.)

Node types

Under Windows, the node type of a networked computer relates to the way it resolves NetBIOS names to IP addresses. This assumes that there are any IP addresses for the NetBIOS nodes, which is assured only when NetBIOS operates over NBT; thus, node types are not a property of NetBIOS per se but of interaction between NetBIOS and TCP/IP in the Windows OS environment. There are four node types.

  • B-node: 0x01 Broadcast
  • P-node: 0x02 Peer (WINS only)
  • M-node: 0x04 Mixed (broadcast, then WINS)
  • H-node: 0x08 Hybrid (WINS, then broadcast)

The node type in use is displayed by opening a command line and typing ipconfig /all. A Windows computer registry may also be configured in such a way as to display "unknown" for the node type.

NetBIOS Suffixes

The NetBIOS Suffix, alternately called the NetBIOS End Character (endchar), is the 16th character of a NetBIOS name and indicates service type for the registered name. The number of record types is limited to 255; some commonly used values are:

For unique names:

For group names:

  • 00: Workstation Service (workgroup/domain name)
  • 1C: Domain Controllers for a domain (group record with up to 25 IP addresses)
  • 1E: Browser Service Elections

Protocol stack

The following table shows a brief history of NetBIOS and its related protocols. SMB was the main protocol that used NetBIOS. SMB enables Windows File and Printer Sharing.

7 Application layer Windows Chat, ClipBook Viewer, Microsoft Hearts SMB SMB SMB SMB SMB
6 Presentation layer NetDDE
5 Session layer NetBIOS (The original "Network Basic Input/Output System") NetBIOS (NetBIOS Frames, incorrectly labeled as "NetBEUI" in Windows) NetBIOS (NetBIOS over IPX/SPX) NetBIOS (NetBIOS over TCP/IP)
4 Transport layer IPX/SPX TCP/UDP TCP/UDP QUIC (over UDP)
3 Network layer IPX IP IP IP
2 Data link layer IEEE 802.2 on Ethernet, Token Ring Any link that carries IPX Any link that carries IP Any link that carries IP Any link that carries IP
1 Physical layer IBM PC Network Ethernet, Token Ring
First supported Windows for Workgroups 3.1 Windows for Workgroups 3.1 Windows NT 3.5 Windows 2000 Windows 11 (Server side requires Windows Server 2022 Datacenter: Azure Edition)
Last supported Windows XP (requires manual install) Windows XP

See also

References

  1. ^ Sosinsky, Barrie (2009). Networking Bible. John Wiley & Sons. pp. 528. ISBN 9780470543429.
  2. "10. Assessing Windows Networking Services - Network Security Assessment, 2nd Edition [Book]". www.oreilly.com. Archived from the original on 20 April 2023. Retrieved 20 April 2023.
  3. "Getaway hardware for protocols". www.networking-hardware.com. Archived from the original on 26 March 2023. Retrieved 20 April 2023.
  4. "Early Microsoft Networks | OS/2 Museum". Retrieved 4 September 2024.
  5. "[MS-WPO]: WINS Management Protocol". learn.microsoft.com. 14 February 2019. Archived from the original on 17 June 2023. Retrieved 17 June 2023. Because the NetBIOS protocol, defined in , does not support the mapping between NetBIOS names and IPv6 addresses, the Remote Administrative Interface: WINS protocol applies only to IPv4 addresses. It does not apply to IPv6 addresses.
  6. ^ "Naming conventions in Active Directory for computers, domains, sites, and OUs". Microsoft. Archived from the original on 22 December 2017. Retrieved 19 December 2017.

Further reading

  • Haugdahl, J. Scott (1990). Inside NetBIOS. Architecture Technology Corp. ISBN 99914-57-34-8
  • Silberschatz, Abraham; Galvin, Peter Baer; Gagne, Greg (2004). Operating System Concepts. (7th Ed.). John Wiley & Sons. ISBN 0-471-69466-5
  • Meyers, Michael (2004). "Managing and Troubleshooting Networks". McGraw-Hill. ISBN 978-0-07-225665-9
  • Tamara Dean. Network+ Guide to Networks, pg. 206 (NetBEUI)

External links

Category: