`Network Working Group
`Request for Comments: 1002 March, 1987
`
`
`
`
` PROTOCOL STANDARD FOR A NetBIOS SERVICE
` ON A TCP/UDP TRANSPORT:
` DETAILED SPECIFICATIONS
`
`
`
`
` ABSTRACT
`
`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 a NetBIOS
`Service on a TCP/UDP Transport: Concepts and Methods".
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`NetBIOS Working Group [Page 1]
`
`
`
`Samsung - Exhibit 1032 - Page 1
`
`

`

`RFC 1002 March 1987
`
`
` TABLE OF CONTENTS
`
`
`1. STATUS OF THIS MEMO 4
`
`2. ACKNOWLEDGEMENTS 4
`
`3. INTRODUCTION 5
`
`4. PACKET DESCRIPTIONS 5
` 4.1 NAME FORMAT 5
` 4.2 NAME SERVICE PACKETS 7
` 4.2.1 GENERAL FORMAT OF NAME SERVICE PACKETS 7
` 4.2.1.1 HEADER 8
` 4.2.1.2 QUESTION SECTION 10
` 4.2.1.3 RESOURCE RECORD 11
` 4.2.2 NAME REGISTRATION REQUEST 13
` 4.2.3 NAME OVERWRITE REQUEST & DEMAND 14
` 4.2.4 NAME REFRESH REQUEST 15
` 4.2.5 POSITIVE NAME REGISTRATION RESPONSE 16
` 4.2.6 NEGATIVE NAME REGISTRATION RESPONSE 16
` 4.2.7 END-NODE CHALLENGE REGISTRATION RESPONSE 17
` 4.2.8 NAME CONFLICT DEMAND 18
` 4.2.9 NAME RELEASE REQUEST & DEMAND 19
` 4.2.10 POSITIVE NAME RELEASE RESPONSE 20
` 4.2.11 NEGATIVE NAME RELEASE RESPONSE 20
` 4.2.12 NAME QUERY REQUEST 21
` 4.2.13 POSITIVE NAME QUERY RESPONSE 22
` 4.2.14 NEGATIVE NAME QUERY RESPONSE 23
` 4.2.15 REDIRECT NAME QUERY RESPONSE 24
` 4.2.16 WAIT FOR ACKNOWLEDGEMENT (WACK) RESPONSE 25
` 4.2.17 NODE STATUS REQUEST 26
` 4.2.18 NODE STATUS RESPONSE 27
` 4.3 SESSION SERVICE PACKETS 29
` 4.3.1 GENERAL FORMAT OF SESSION PACKETS 29
` 4.3.2 SESSION REQUEST PACKET 30
` 4.3.3 POSITIVE SESSION RESPONSE PACKET 31
` 4.3.4 NEGATIVE SESSION RESPONSE PACKET 31
` 4.3.5 SESSION RETARGET RESPONSE PACKET 31
` 4.3.6 SESSION MESSAGE PACKET 32
` 4.3.7 SESSION KEEP ALIVE PACKET 32
` 4.4 DATAGRAM SERVICE PACKETS 32
` 4.4.1 NetBIOS DATAGRAM HEADER 32
` 4.4.2 DIRECT_UNIQUE, DIRECT_GROUP, & BROADCAST DATAGRAM 33
` 4.4.3 DATAGRAM ERROR PACKET 34
` 4.4.4 DATAGRAM QUERY REQUEST 34
` 4.4.5 DATAGRAM POSITIVE AND NEGATIVE QUERY RESPONSE 34
`
`5. PROTOCOL DESCRIPTIONS 35
` 5.1 NAME SERVICE PROTOCOLS 35
` 5.1.1 B-NODE ACTIVITY 35
`
`
`
`NetBIOS Working Group [Page 2]
`
`
`
`Samsung - Exhibit 1032 - Page 2
`
`

`

`RFC 1002 March 1987
`
`
` 5.1.1.1 B-NODE ADD NAME 35
` 5.1.1.2 B-NODE ADD_GROUP NAME 37
` 5.1.1.3 B-NODE FIND_NAME 37
` 5.1.1.4 B NODE NAME RELEASE 38
` 5.1.1.5 B-NODE INCOMING PACKET PROCESSING 39
` 5.1.2 P-NODE ACTIVITY 42
` 5.1.2.1 P-NODE ADD_NAME 42
` 5.1.2.2 P-NODE ADD GROUP NAME 45
` 5.1.2.3 P-NODE FIND NAME 45
` 5.1.2.4 P-NODE DELETE_NAME 46
` 5.1.2.5 P-NODE INCOMING PACKET PROCESSING 47
` 5.1.2.6 P-NODE TIMER INITIATED PROCESSING 49
` 5.1.3 M-NODE ACTIVITY 50
` 5.1.3.1 M-NODE ADD NAME 50
` 5.1.3.2 M-NODE ADD GROUP NAME 54
` 5.1.3.3 M-NODE FIND NAME 55
` 5.1.3.4 M-NODE DELETE NAME 56
` 5.1.3.5 M-NODE INCOMING PACKET PROCESSING 58
` 5.1.3.6 M-NODE TIMER INITIATED PROCESSING 60
` 5.1.4 NBNS ACTIVITY 60
` 5.1.4.1 NBNS INCOMING PACKET PROCESSING 61
` 5.1.4.2 NBNS TIMER INITIATED PROCESSING 66
` 5.2 SESSION SERVICE PROTOCOLS 67
` 5.2.1 SESSION ESTABLISHMENT PROTOCOLS 67
` 5.2.1.1 USER REQUEST PROCESSING 67
` 5.2.1.2 RECEIVED PACKET PROCESSING 71
` 5.2.2 SESSION DATA TRANSFER PROTOCOLS 72
` 5.2.2.1 USER REQUEST PROCESSING 72
` 5.2.2.2 RECEIVED PACKET PROCESSING 72
` 5.2.2.3 PROCESSING INITIATED BY TIMER 73
` 5.2.3 SESSION TERMINATION PROTOCOLS 73
` 5.2.3.1 USER REQUEST PROCESSING 73
` 5.2.3.2 RECEPTION INDICATION PROCESSING 73
` 5.3 NetBIOS DATAGRAM SERVICE PROTOCOLS 74
` 5.3.1 B NODE TRANSMISSION OF NetBIOS DATAGRAMS 74
` 5.3.2 P AND M NODE TRANSMISSION OF NetBIOS DATAGRAMS 76
` 5.3.3 RECEPTION OF NetBIOS DATAGRAMS BY ALL NODES 78
` 5.3.4 PROTOCOLS FOR THE NBDD 80
`
`6. DEFINED CONSTANTS AND VARIABLES 83
`
`REFERENCES 85
`
`
`
`
`
`
`
`
`
`
`
`
`NetBIOS Working Group [Page 3]
`
`
`
`Samsung - Exhibit 1032 - Page 3
`
`

`

`RFC 1002 March 1987
`
`
` PROTOCOL STANDARD FOR A NetBIOS SERVICE
` ON A TCP/UDP TRANSPORT:
` DETAILED SPECIFICATIONS
`
`
`1. STATUS OF THIS MEMO
`
` This RFC specifies a proposed standard for the DARPA Internet
` community. Since this topic is new to the Internet community,
` discussions and suggestions are specifically requested.
`
` Please send written comments to:
`
` Karl Auerbach
` Epilogue Technology Corporation
` P.O. Box 5432
` Redwood City, CA 94063
`
` Please send online comments to:
`
` Avnish Aggarwal
` Internet: mtxinu!excelan!avnish@ucbvax.berkeley.edu
` Usenet: ucbvax!mtxinu!excelan!avnish
`
` Distribution of this memorandum is unlimited.
`
`2. ACKNOWLEDGEMENTS
`
` This RFC has been developed under the auspices of the Internet
` Activities Board.
`
` The following individuals have contributed to the development of
` this RFC:
`
` Avnish Aggarwal Arvind Agrawal Lorenzo Aguilar
` Geoffrey Arnold Karl Auerbach K. Ramesh Babu
` Keith Ball Amatzia Ben-Artzi Vint Cerf
` Richard Cherry David Crocker Steve Deering
` Greg Ennis Steve Holmgren Jay Israel
` David Kaufman Lee LaBarre James Lau
` Dan Lynch Gaylord Miyata David Stevens
` Steve Thomas Ishan Wu
`
` The system proposed by this RFC does not reflect any existing
` Netbios-over-TCP implementation. However, the design
` incorporates considerable knowledge obtained from prior
` implementations. Special thanks goes to the following
` organizations which have provided this invaluable information:
`
` CMC/Syros Excelan Sytek Ungermann-Bass
`
`
`
`
`NetBIOS Working Group [Page 4]
`
`
`
`Samsung - Exhibit 1032 - Page 4
`
`

`

`RFC 1002 March 1987
`
`
`3. INTRODUCTION
`
` This RFC contains the detailed packet formats and protocol
` specifications for NetBIOS-over-TCP. This RFC is a companion to
` RFC 1001, "Protocol Standard For a NetBIOS Service on a TCP/UDP
` Transport: Concepts and Methods" [1].
`
`4. PACKET DESCRIPTIONS
`
` Bit and byte ordering are defined by the most recent version of
` "Assigned Numbers" [2].
`
`4.1. NAME FORMAT
`
` The NetBIOS name representation in all NetBIOS packets (for NAME,
` SESSION, and DATAGRAM services) is defined in the Domain Name
` Service RFC 883[3] as "compressed" name messages. This format is
` called "second-level encoding" in the section entitled
` "Representation of NetBIOS Names" in the Concepts and Methods
` document.
`
` For ease of description, the first two paragraphs from page 31,
` the section titled "Domain name representation and compression",
` of RFC 883 are replicated here:
`
` Domain names messages are expressed in terms of a sequence
` of labels. Each label is represented as a one octet length
` field followed by that number of octets. Since every domain
` name ends with the null label of the root, a compressed
` domain name is terminated by a length byte of zero. The
` high order two bits of the length field must be zero, and
` the remaining six bits of the length field limit the label
` to 63 octets or less.
`
` To simplify implementations, the total length of label
` octets and label length octets that make up a domain name is
` restricted to 255 octets or less.
`
` The following is the uncompressed representation of the NetBIOS name
` "FRED ", which is the 4 ASCII characters, F, R, E, D, followed by 12
` space characters (0x20). This name has the SCOPE_ID: "NETBIOS.COM"
`
` EGFCEFEECACACACACACACACACACACACA.NETBIOS.COM
`
` This uncompressed representation of names is called "first-level
` encoding" in the section entitled "Representation of NetBIOS Names"
` in the Concepts and Methods document.
`
` The following is a pictographic representation of the compressed
` representation of the previous uncompressed Domain Name
` representation.
`
`
`
`NetBIOS Working Group [Page 5]
`
`
`
`Samsung - Exhibit 1032 - Page 5
`
`

`

`RFC 1002 March 1987
`
`
` 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
` 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
` +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
` | 0x20 | E (0x45) | G (0x47) | F (0x46) |
` +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
` | C (0x43) | E (0x45) | F (0x46) | E (0x45) |
` +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
` | E (0x45) | C (0x43) | A (0x41) | C (0x43) |
` +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
` | A (0x41) | C (0x43) | A (0x41) | C (0x43) |
` +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
` | A (0x41) | C (0x43) | A (0x41) | C (0x43) |
` +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
` | A (0x41) | C (0x43) | A (0x41) | C (0x43) |
` +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
` | A (0x41) | C (0x43) | A (0x41) | C (0x43) |
` +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
` | A (0x41) | C (0x43) | A (0x41) | C (0x43) |
` +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
` | A (0X41) | 0x07 | N (0x4E) | E (0x45) |
` +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
` | T (0x54) | B (0x42) | I (0x49) | O (0x4F) |
` +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
` | S (0x53) | 0x03 | C (0x43) | O (0x4F) |
` +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
` | M (0x4D) | 0x00 |
` +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
`
` Each section of a domain name is called a label [7 (page 31)]. A
` label can be a maximum of 63 bytes. The first byte of a label in
` compressed representation is the number of bytes in the label. For
` the above example, the first 0x20 is the number of bytes in the
` left-most label, EGFCEFEECACACACACACACACACACACACA, of the domain
` name. The bytes following the label length count are the characters
` of the label. The following labels are in sequence after the first
` label, which is the encoded NetBIOS name, until a zero (0x00) length
` count. The zero length count represents the root label, which is
` always null.
`
` A label length count is actually a 6-bit field in the label length
` field. The most significant 2 bits of the field, bits 7 and 6, are
` flags allowing an escape from the above compressed representation.
` If bits 7 and 6 are both set (11), the following 14 bits are an
` offset pointer into the full message to the actual label string from
` another domain name that belongs in this name. This label pointer
` allows for a further compression of a domain name in a packet.
`
` NetBIOS implementations can only use label string pointers in Name
` Service packets. They cannot be used in Session or Datagram Service
` packets.
`
`
`
`
`NetBIOS Working Group [Page 6]
`
`
`
`Samsung - Exhibit 1032 - Page 6
`
`

`

`RFC 1002 March 1987
`
`
` The other two possible values for bits 7 and 6 (01 and 10) of a label
` length field are reserved for future use by RFC 883[2 (page 32)].
`
` Note that the first octet of a compressed name must contain one of
` the following bit patterns. (An "x" indicates a bit whose value may
` be either 0 or 1.):
`
` 00100000 - Netbios name, length must be 32 (decimal)
` 11xxxxxx - Label string pointer
` 10xxxxxx - Reserved
` 01xxxxxx - Reserved
`
`4.2. NAME SERVICE PACKETS
`
`4.2.1. GENERAL FORMAT OF NAME SERVICE PACKETS
`
` The NetBIOS Name Service packets follow the packet structure defined
` in the Domain Name Service (DNS) RFC 883 [7 (pg 26-31)]. The
` structures are compatible with the existing DNS packet formats,
` however, additional types and codes have been added to work with
` NetBIOS.
`
` If Name Service packets are sent over a TCP connection they are
` preceded by a 16 bit unsigned integer representing the length of the
` Name Service packet.
`
` 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
` 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
` +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
` | |
` + ------ ------- +
` | HEADER |
` + ------ ------- +
` | |
` +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
` | |
` / QUESTION ENTRIES /
` | |
` +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
` | |
` / ANSWER RESOURCE RECORDS /
` | |
` +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
` | |
` / AUTHORITY RESOURCE RECORDS /
` | |
` +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
` | |
` / ADDITIONAL RESOURCE RECORDS /
` | |
` +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
`
`
`
`NetBIOS Working Group [Page 7]
`
`
`
`Samsung - Exhibit 1032 - Page 7
`
`

`

`RFC 1002 March 1987
`
`
`4.2.1.1. HEADER
`
` 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
` 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
` +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
` | NAME_TRN_ID | OPCODE | NM_FLAGS | RCODE |
` +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
` | QDCOUNT | ANCOUNT |
` +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
` | NSCOUNT | ARCOUNT |
` +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
`
` Field Description
`
` NAME_TRN_ID Transaction ID for Name Service Transaction.
` Requestor places a unique value for each active
` transaction. Responder puts NAME_TRN_ID value
` from request packet in response packet.
`
` OPCODE Packet type code, see table below.
`
` NM_FLAGS Flags for operation, see table below.
`
` RCODE Result codes of request. Table of RCODE values
` for each response packet below.
`
` QDCOUNT Unsigned 16 bit integer specifying the number of
` entries in the question section of a Name
`
` Service packet. Always zero (0) for responses.
` Must be non-zero for all NetBIOS Name requests.
`
` ANCOUNT Unsigned 16 bit integer specifying the number of
` resource records in the answer section of a Name
` Service packet.
`
` NSCOUNT Unsigned 16 bit integer specifying the number of
` resource records in the authority section of a
` Name Service packet.
`
` ARCOUNT Unsigned 16 bit integer specifying the number of
` resource records in the additional records
` section of a Name Service packet.
`
` The OPCODE field is defined as:
`
` 0 1 2 3 4
` +---+---+---+---+---+
` | R | OPCODE |
` +---+---+---+---+---+
`
`
`
`
`NetBIOS Working Group [Page 8]
`
`
`
`Samsung - Exhibit 1032 - Page 8
`
`

`

`RFC 1002 March 1987
`
`
` Symbol Bit(s) Description
`
` OPCODE 1-4 Operation specifier:
` 0 = query
` 5 = registration
` 6 = release
` 7 = WACK
` 8 = refresh
`
` R 0 RESPONSE flag:
` if bit == 0 then request packet
` if bit == 1 then response packet.
`
` The NM_FLAGS field is defined as:
`
`
` 0 1 2 3 4 5 6
` +---+---+---+---+---+---+---+
` |AA |TC |RD |RA | 0 | 0 | B |
` +---+---+---+---+---+---+---+
`
` Symbol Bit(s) Description
`
` B 6 Broadcast Flag.
` = 1: packet was broadcast or multicast
` = 0: unicast
`
` RA 3 Recursion Available Flag.
`
` Only valid in responses from a NetBIOS Name
` Server -- must be zero in all other
` responses.
`
` If one (1) then the NBNS supports recursive
` query, registration, and release.
`
` If zero (0) then the end-node must iterate
` for query and challenge for registration.
`
` RD 2 Recursion Desired Flag.
`
` May only be set on a request to a NetBIOS
` Name Server.
`
` The NBNS will copy its state into the
` response packet.
`
` If one (1) the NBNS will iterate on the
` query, registration, or release.
`
` TC 1 Truncation Flag.
`
`
`
`NetBIOS Working Group [Page 9]
`
`
`
`Samsung - Exhibit 1032 - Page 9
`
`

`

`RFC 1002 March 1987
`
`
` Set if this message was truncated because the
` datagram carrying it would be greater than
` 576 bytes in length. Use TCP to get the
` information from the NetBIOS Name Server.
`
` AA 0 Authoritative Answer flag.
`
` Must be zero (0) if R flag of OPCODE is zero
` (0).
`
` If R flag is one (1) then if AA is one (1)
` then the node responding is an authority for
` the domain name.
`
` End nodes responding to queries always set
` this bit in responses.
`
`4.2.1.2. QUESTION SECTION
`
` 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
` 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
` +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
` | |
` / QUESTION_NAME /
` / /
` | |
` +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
` | QUESTION_TYPE | QUESTION_CLASS |
` +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
`
` Field Description
`
` QUESTION_NAME The compressed name representation of the
` NetBIOS name for the request.
`
` QUESTION_TYPE The type of request. The values for this field
` are specified for each request.
`
` QUESTION_CLASS The class of the request. The values for this
` field are specified for each request.
`
` QUESTION_TYPE is defined as:
`
` Symbol Value Description:
`
` NB 0x0020 NetBIOS general Name Service Resource Record
` NBSTAT 0x0021 NetBIOS NODE STATUS Resource Record (See NODE
` STATUS REQUEST)
`
` QUESTION_CLASS is defined as:
`
`
`
`
`NetBIOS Working Group [Page 10]
`
`
`
`Samsung - Exhibit 1032 - Page 10
`
`

`

`RFC 1002 March 1987
`
`
` Symbol Value Description:
`
` IN 0x0001 Internet class
`
`4.2.1.3. RESOURCE RECORD
`
` 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
` 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
` +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
` | |
` / RR_NAME /
` / /
` | |
` +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
` | RR_TYPE | RR_CLASS |
` +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
` | TTL |
` +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
` | RDLENGTH | |
` +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
` / /
` / RDATA /
` | |
` +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
`
` Field Description
`
` RR_NAME The compressed name representation of the
` NetBIOS name corresponding to this resource
` record.
`
` RR_TYPE Resource record type code
`
` RR_CLASS Resource record class code
`
` TTL The Time To Live of a the resource record's
` name.
`
` RDLENGTH Unsigned 16 bit integer that specifies the
` number of bytes in the RDATA field.
`
` RDATA RR_CLASS and RR_TYPE dependent field. Contains
` the resource information for the NetBIOS name.
`
` RESOURCE RECORD RR_TYPE field definitions:
`
` Symbol Value Description:
`
` A 0x0001 IP address Resource Record (See REDIRECT NAME
` QUERY RESPONSE)
` NS 0x0002 Name Server Resource Record (See REDIRECT
`
`
`
`NetBIOS Working Group [Page 11]
`
`
`
`Samsung - Exhibit 1032 - Page 11
`
`

`

`RFC 1002 March 1987
`
`
` NAME QUERY RESPONSE)
` NULL 0x000A NULL Resource Record (See WAIT FOR
` ACKNOWLEDGEMENT RESPONSE)
` NB 0x0020 NetBIOS general Name Service Resource Record
` (See NB_FLAGS and NB_ADDRESS, below)
` NBSTAT 0x0021 NetBIOS NODE STATUS Resource Record (See NODE
` STATUS RESPONSE)
`
` RESOURCE RECORD RR_CLASS field definitions:
`
` Symbol Value Description:
`
` IN 0x0001 Internet class
`
` NB_FLAGS field of the RESOURCE RECORD RDATA field for RR_TYPE of
` "NB":
`
` 1 1 1 1 1 1
` 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
` +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
` | G | ONT | RESERVED |
` +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
`
` Symbol Bit(s) Description:
`
` RESERVED 3-15 Reserved for future use. Must be zero (0).
` ONT 1,2 Owner Node Type:
` 00 = B node
` 01 = P node
` 10 = M node
` 11 = Reserved for future use
` For registration requests this is the
` claimant's type.
` For responses this is the actual owner's
` type.
`
` G 0 Group Name Flag.
` If one (1) then the RR_NAME is a GROUP
` NetBIOS name.
` If zero (0) then the RR_NAME is a UNIQUE
` NetBIOS name.
`
` The NB_ADDRESS field of the RESOURCE RECORD RDATA field for
` RR_TYPE of "NB" is the IP address of the name's owner.
`
`
`
`
`
`
`
`
`
`
`NetBIOS Working Group [Page 12]
`
`
`
`Samsung - Exhibit 1032 - Page 12
`
`

`

`RFC 1002 March 1987
`
`
`4.2.2. NAME REGISTRATION REQUEST
`
` 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
` 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
` +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
` | NAME_TRN_ID |0| 0x5 |0|0|1|0|0 0|B| 0x0 |
` +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
` | 0x0001 | 0x0000 |
` +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
` | 0x0000 | 0x0001 |
` +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
` | |
` / QUESTION_NAME /
` / /
` | |
` +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
` | NB (0x0020) | IN (0x0001) |
` +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
` | |
` / RR_NAME /
` / /
` | |
` +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
` | NB (0x0020) | IN (0x0001) |
` +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
` | TTL |
` +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
` | 0x0006 | NB_FLAGS |
` +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
` | NB_ADDRESS |
` +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
`
` Since the RR_NAME is the same name as the QUESTION_NAME, the
` RR_NAME representation must use pointers to the QUESTION_NAME
` name's labels to guarantee the length of the datagram is less
` than the maximum 576 bytes. See section above on name formats
` and also page 31 and 32 of RFC 883, Domain Names - Implementation
` and Specification, for a complete description of compressed name
` label pointers.
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`NetBIOS Working Group [Page 13]
`
`
`
`Samsung - Exhibit 1032 - Page 13
`
`

`

`RFC 1002 March 1987
`
`
`4.2.3. NAME OVERWRITE REQUEST & DEMAND
`
` 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
` 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
` +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
` | NAME_TRN_ID |0| 0x5 |0|0|0|0|0 0|B| 0x0 |
` +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
` | 0x0001 | 0x0000 |
` +-+-+-+-+-+-+