Protocol standard for a NetBIOS service on a TCP/UDP transport: Concepts and methods
also
- std-19
Extracted elements (28)
NetBIOS names are encoded using half-nibble biased-ASCII encoding and appended with a DNS-compatible scope identifier so that the composite name is a valid DNS domain name. This alignment is intentional to enable potential future use of DNS infrastructure as an NBNS, requiring only extensions for dynamic registration, group entries, TTL refresh, and new attributes.
P and M node types were introduced specifically to minimize broadcast activity, motivated by the need for internet operation across IP routers (which do not forward broadcasts) and to reduce the burden on non-participating hosts that must otherwise receive and discard every NetBIOS broadcast.
The NBNS may operate in 'secured' mode (actively challenging and validating name ownership) or 'non-secured' mode (a passive bulletin board delegating consistency to end-nodes). This tradeoff lets administrators balance NBNS implementation simplicity, security guarantees, and name registration latency.
The protocol favors using existing standards unmodified over inventing new protocols (section 4.2/4.11). When no existing protocol fully covers a needed function, the preferred approach is to make the smallest possible extension rather than define a wholly new protocol, in order to reduce standardization burden and maximize general Internet utility.
B nodes and M nodes must not be intermixed in an internet (routed) environment because B node broadcasts do not cross IP routers; doing so would allow undetected NetBIOS name conflicts between the broadcast domain and the routed internet, causing unpredictable behavior.
An end-node may maintain a local cache of NetBIOS name-to-IP address entries; all cache entries should be flushed periodically. Cache entries for a given IP address must be flushed whenever any indication of trouble with the node at that address is received (e.g., upon sending a NAME CONFLICT DEMAND to that node).
Because UDP is unreliable, each request must be retransmitted if no response is received within a specified timeout. Duplicate responses triggered by retransmission are silently ignored by comparing transaction ID and NetBIOS information; stateless responders simply re-answer every received request.
Every end-node must respond in a timely fashion to NAME QUERY REQUEST challenges and NODE STATUS REQUEST packets from any node or NBNS. Failure to respond permits the NBNS to consider the end-node to have released all its registered names.
For end-node to NBNS transactions, either UDP or TCP may be used as transport. If a UDP response is truncated, the NBNS sets a truncation flag; the end-node may then open a TCP connection and repeat the request to receive the complete, untruncated response.
Names held by an NBNS are assigned a lifetime during registration negotiation: the end-node proposes a lifetime; the NBNS sets the actual value and may respond with any definite period greater than or equal to that proposed. The end-node must send NAME REFRESH REQUEST packets before lifetime expiry or the NBNS considers the name silently released.
A NetBIOS Scope is the population of computers across which a registered NetBIOS name is known; it is identified by a scope identifier that meets DNS domain name syntax requirements. An internet may support multiple non-intersecting NetBIOS scopes.
Demands are imperative requests that have no matching response and are not retransmitted (e.g., NAME OVERWRITE DEMAND, NAME CONFLICT DEMAND). They are used only where limited damage would result from packet loss.
Interactions are grouped into transactions identified by a 16-bit transaction ID chosen by the originator and echoed in all request/response pairs. Responses must be matched by both transaction ID and source IP address; unmatched or stale responses must be discarded.
Name challenge verifies current ownership by sending a NAME QUERY REQUEST to the alleged owner; failure to respond causes the challenger to consider the name released. A challenge may be issued by any NBNS, P node, or M node against any end-node type at any time.
Name query retrieves the IP address(es) associated with a NetBIOS name. B nodes broadcast a NAME QUERY REQUEST; P nodes query the NBNS directly; M nodes broadcast first and, if unsuccessful, query the NBNS. All node types use the same packet formats for queries and responses.
Session keep-alive packets are exchanged during the steady-state data transfer phase to detect loss of the TCP connection in the absence of application data. Session data is encapsulated with a NetBIOS session header over the TCP byte stream.
The NetBIOS Datagram Service is connectionless and unreliable, supporting unicast, multicast (to all holders of a group name), and broadcast delivery. B nodes use UDP broadcast directly; P and M nodes use the NBDD for multicast and broadcast distribution. NetBIOS datagrams that exceed a single UDP packet are fragmented at the NetBIOS level.
The NetBIOS Session Service provides reliable, full-duplex, sequenced message exchange over TCP between a pair of named NetBIOS applications. Messages range from 0 to 131,071 bytes. Session establishment involves a CALL/LISTEN phase; a RETARGET response may redirect the caller to a different IP address and port.
Three end-node types are defined: Broadcast (B) nodes use UDP broadcast and TCP for name and datagram operations; Point-to-point (P) nodes use only directed UDP and TCP, relying on NBNS and NBDD servers; Mixed mode (M) nodes combine B and P behaviors, broadcasting first then falling back to NBNS.
Two support server types are defined: the NetBIOS Name Server (NBNS) manages name registration and resolution for P and M nodes; the NetBIOS Datagram Distribution Server (NBDD) handles datagram multicast and broadcast distribution across an internet. Neither interacts with B nodes.
While processing a long-running name service request, the NBNS may send a WAIT FOR ACKNOWLEDGEMENT RESPONSE (WACK) to assure the requesting end-node that the NBNS is still operational and actively processing the request.
The specification acknowledges that NetBIOS networks can be disrupted by malicious behavior (section 4.4). A non-secured NBNS performs no validation of name ownership claims, allowing any node to register or overwrite names without challenge. Deliberate injection of NAME CONFLICT DEMAND packets can render a name unusable on victim nodes, disrupting all sessions and datagrams associated with that name.
B node name registration: broadcasts NAME REGISTRATION REQUEST; if no NEGATIVE NAME REGISTRATION RESPONSE is received within CONFLICT_TIMER (retried BCAST_REQ_RETRY_COUNT times), the name is acquired and a NAME OVERWRITE DEMAND is broadcast. A single negative response terminates the attempt.
M node name registration begins with a B-node-style broadcast; any NEGATIVE NAME REGISTRATION RESPONSE terminates the attempt. If no negative response is received, the M node continues with P-node registration via the NBNS. Both phases must succeed for the name to be acquired.
Name conflict arises when a unique name is held by more than one node. B and M nodes detect conflict by receiving inconsistent responses to broadcast name queries within CONFLICT_TIMER; the detector sends NAME CONFLICT DEMAND to the offending node. Any end-node receiving NAME CONFLICT DEMAND must mark the name conflicted in its local name table, ceasing all use except DELETE NAME.
P node name registration differs by NBNS type: a non-secured NBNS returns an END-NODE CHALLENGE REGISTRATION RESPONSE delegating conflict resolution to the registrant; a secured NBNS challenges prior holders itself and returns POSITIVE or NEGATIVE NAME REGISTRATION RESPONSE directly. A WACK may be issued while challenges are pending.
First-level encoding maps each 4-bit half-octet of the 16-byte NetBIOS name into one byte by adding ASCII 'A' (0x41), producing a 32-byte uppercase string from the set {A–P}. The NetBIOS scope identifier is appended after a dot, forming a valid DNS domain name.
Second-level encoding compresses the first-level domain name per RFC 883 domain name representation and compression rules. This compressed form is the only NetBIOS name representation used in NetBIOS-over-TCP packet formats, except in the RDATA field of a NODE STATUS RESPONSE.