rfc-1002

Protocol standard for a NetBIOS service on a TCP/UDP transport: Detailed specifications

NetBIOS Working Group in the Defense Advanced Research Projects Agency, Internet Activities Board, End-to-End Services Task Force
date1987-03 streamLegacy statusINTERNET STANDARD pages84 canonicalhttps://www.rfc-editor.org/rfc/rfc1002 doi10.17487/RFC1002 errataview
This RFC defines a proposed standard protocol to support NetBIOS services in a TCP/IP environment. Both local network and internet operation are supported. Various node types are defined to accommodate local and internet topologies and to allow operation with or without the use of IP broadcast. This RFC gives the detailed specifications of the netBIOS-over-TCP packets, protocols, and defined constants and variables. A more general overview is found in a companion RFC, "Protocol Standard For NetBIOS Service on TCP/UDP Transport: Concepts and Methods".

also

Extracted elements (30)

design-rationale §4.2.1

Name Service packets are deliberately structured to be compatible with DNS RFC 883 packet formats, reusing the header, question section, and resource record layouts. Additional NetBIOS-specific OPCODE values and resource record types (NB=0x0020, NBSTAT=0x0021) are layered on top of the DNS framework to leverage existing DNS infrastructure and implementations.

dns

interoperability-note §4.2.15

An end node responding to a NAME QUERY REQUEST always sets the AA and RA bits in both positive and negative responses. An end node never sends a REDIRECT NAME QUERY RESPONSE; only an NBNS sends redirect responses.

normative-requirement §4.2.1 MUST

Name Service packets sent over TCP must be preceded by a 16-bit unsigned integer representing the length of the Name Service packet.

tcp

normative-requirement §4.1 MUST NOT

NetBIOS implementations can only use label string pointers in Name Service packets. They cannot be used in Session or Datagram Service packets.

dns

normative-requirement §4.2.1.1 MUST

The TC (Truncation) flag must be set if the Name Service message would exceed 576 bytes in a datagram. When TC is set, the client should use TCP to retrieve the full response from the NBNS.

tcp, udp

protocol-element §4.4.1

Datagram MSG_TYPE values: 0x10=DIRECT_UNIQUE, 0x11=DIRECT_GROUP, 0x12=BROADCAST, 0x13=DATAGRAM ERROR, 0x14=DATAGRAM QUERY REQUEST, 0x15=DATAGRAM POSITIVE QUERY RESPONSE, 0x16=DATAGRAM NEGATIVE QUERY RESPONSE.

udp

protocol-element §4.3.4

Negative Session Response ERROR_CODE values: 0x80=not listening on called name, 0x81=not listening for calling name, 0x82=called name not present, 0x83=called name present but insufficient resources, 0x8F=unspecified error.

tcp

protocol-element §4.2.1.1

NM_FLAGS contains: AA (Authoritative Answer), TC (Truncation—set when datagram would exceed 576 bytes), RD (Recursion Desired—only valid in requests to NBNS), RA (Recursion Available—only valid in NBNS responses), and B (Broadcast/multicast flag). RA must be zero in all non-NBNS responses.

protocol-element §4.2.1.1

OPCODE field encodes packet operation: 0=query, 5=registration, 6=release, 7=WACK, 8=refresh. The R bit (bit 0 of OPCODE field) distinguishes requests (0) from responses (1).

protocol-element §4.2.6

RCODE values for negative name registration responses: FMT_ERR=0x1 (format error), SRV_ERR=0x2 (server failure), IMP_ERR=0x4 (unsupported request), RFS_ERR=0x5 (refused by policy), ACT_ERR=0x6 (name owned by another node), CFT_ERR=0x7 (UNIQUE name owned by more than one node).

protocol-element §4.3.1

Session packet TYPE values: 0x00=SESSION MESSAGE, 0x81=SESSION REQUEST, 0x82=POSITIVE SESSION RESPONSE, 0x83=NEGATIVE SESSION RESPONSE, 0x84=RETARGET SESSION RESPONSE, 0x85=SESSION KEEP ALIVE.

tcp

protocol-element §4.2.7

The End-Node Challenge Registration Response (OPCODE=5, RA=0) is sent by NBNS to instruct the requesting node to challenge the current owner of the name directly before registration is granted.

protocol-element §5.1

Three node types are defined: B-node (broadcast node—uses IP broadcast for name resolution, no NBNS required), P-node (point-to-point—uses NBNS unicast only, no broadcast), and M-node (mixed—uses broadcast first, falls back to NBNS). The NBNS (NetBIOS Name Server) and NBDD (NetBIOS Datagram Distribution server) are also defined.

security-consideration §5.1.1

B-node name registration relies entirely on IP broadcast and the honesty of other nodes: any node can respond to a registration request with a NEGATIVE response to deny a name, and there is no cryptographic authentication of ownership claims. Name conflict is detected heuristically via CONFLICT_TIMER on query responses.

security

state-machine §5.1.1.1

B-node add-name procedure: repeatedly broadcasts NAME REGISTRATION REQUEST (up to BCAST_REQ_RETRY_TIMEOUT * retry count). If no response received, broadcasts NAME UPDATE REQUEST and adds name to local table (success). If a NEGATIVE NAME REGISTRATION RESPONSE is received with matching tid, returns failure.

state-machine §5.1.1.3

B-node find-name procedure: broadcasts NAME QUERY REQUEST, waits BCAST_REQ_RETRY_TIMEOUT; on POSITIVE NAME QUERY RESPONSE, saves response as authoritative and starts CONFLICT_TIMER to detect additional responders. NEGATIVE and REDIRECT responses are ignored by B-nodes.

state-machine §5.1.1.5

B-node incoming packet processing: on NAME REGISTRATION REQUEST (UNIQUE), sends NEGATIVE response if name exists locally; for GROUP registrations, only sends NEGATIVE if local entry is UNIQUE. NAME QUERY REQUEST triggers a POSITIVE response if name is in local table.

state-machine §5.1.2.1

P-node add-name procedure: sends NAME REGISTRATION REQUEST unicast to NBNS; on POSITIVE response, name is registered; on END-NODE CHALLENGE response, P-node must challenge the current owner via unicast NAME QUERY; on WACK, extends wait timer using TTL from WACK response.

state-machine §5.2.1

Session establishment: caller resolves called name via Name Service, opens TCP connection to resolved address, sends SESSION REQUEST. Callee responds with POSITIVE SESSION RESPONSE, NEGATIVE SESSION RESPONSE (with error code), or RETARGET SESSION RESPONSE. On retarget, caller must close TCP and reconnect to specified IP:port.

tcp

wire-format §4.2.2

Name Registration Request includes QUESTION_NAME and RR_NAME (same name); OPCODE=5 (registration), RD=1, ARCOUNT=1. The RR_NAME must use label string pointers to QUESTION_NAME to keep the datagram under 576 bytes. RDLENGTH is 0x0006 covering NB_FLAGS (2 bytes) and NB_ADDRESS (4 bytes).

wire-format §4.2.1.1

Name Service packet header is 12 bytes: NAME_TRN_ID (16-bit transaction ID), OPCODE (5-bit field with R flag), NM_FLAGS (7-bit flags), RCODE (4-bit result code), QDCOUNT, ANCOUNT, NSCOUNT, and ARCOUNT (each 16 bits). Structure is compatible with DNS RFC 883.

dns

wire-format §4.4.1

NetBIOS Datagram header: MSG_TYPE (1 byte), FLAGS (1 byte), DGM_ID (2 bytes), SOURCE_IP (4 bytes), SOURCE_PORT (2 bytes), DGM_LENGTH (2 bytes), PACKET_OFFSET (2 bytes). FLAGS encode M (more fragments), F (first fragment), and SNT (source end-node type: B/P/M/NBDD).

udp, ip

wire-format §4.1

NetBIOS names are encoded using DNS RFC 883 compressed label format ("second-level encoding"). Each encoded NetBIOS name label is exactly 32 bytes (0x20) long, followed by optional SCOPE_ID labels, terminated by a zero-length octet. The first octet of a compressed name must be 0x20 (NetBIOS name), 0xC0-0xFF (label string pointer), or reserved patterns 0x80-0xBF.

dns

wire-format §4.2.18

Node Status Response NODE_NAME entry: 16 bytes of NETBIOS FORMAT NAME followed by 2-byte NAME_FLAGS. NAME_FLAGS include G (group), ONT (node type), DRG (deregistering), CNF (conflict), ACT (active—always 1), PRM (permanent node name), and RESERVED bits.

wire-format §4.2.18

Node Status STATISTICS block: UNIT_ID (6 bytes, unique adapter ID), JUMPERS (1 byte), TEST_RESULT (1 byte), VERSION_NUMBER (2 bytes), PERIOD_OF_STATISTICS (2 bytes), followed by network error counters and session capacity fields totaling 44+ bytes.

wire-format §4.2.13

Positive Name Query Response contains an ADDR_ENTRY array; each ADDR_ENTRY is 6 bytes: NB_FLAGS (2 bytes) and NB_ADDRESS (4 bytes). For group names, multiple entries may be present. The TC bit is set if the list is truncated due to packet size limits.

ip

wire-format §4.2.1.3

Resource Record RDATA NB_FLAGS field (16 bits): G bit (0) indicates GROUP vs UNIQUE name; ONT bits (1-2) encode Owner Node Type (00=B, 01=P, 10=M, 11=reserved); bits 3-15 are reserved and must be zero. NB_ADDRESS (32 bits) contains the IP address of the name owner.

ip

wire-format §4.3.2

Session Request packet carries CALLED NAME and CALLING NAME (each in NetBIOS compressed name format) as the trailer. Session Retarget Response carries RETARGET_IP_ADDRESS (4 bytes) and PORT (2 bytes), LENGTH=0x0006.

tcp, ip

wire-format §4.3.1

Session service packets are sent over TCP and share a common 4-byte header: TYPE (1 byte), FLAGS (1 byte), LENGTH (2 bytes). The E bit of FLAGS extends LENGTH as a high-order bit, allowing trailer sizes from 0 to 131071 (128K-1) bytes.

tcp

wire-format §4.2.16

WACK (Wait for Acknowledgement) response uses OPCODE=7; TTL field holds the new time-to-wait in seconds. RDATA (2 bytes) contains the OPCODE and NM_FLAGS from the original request. A TTL of 0 means the NBNS cannot estimate the completion time.