RFC1002 日本語訳
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. March 1987. (Format: TXT=170262 bytes) (Also STD0019) (Status: STANDARD)
RFC一覧
英語原文
Network Working Group
Request for Comments: 1002 March, 1987
TCP/UDP トランスポート上における
NetBIOS サービスのためのプロトコル標準:
詳細仕様
概要
この RFC では、TCP/IP 環境において NetBIOS サービスを提供する標準プロ
トコルの提案について記述する。ローカルネットワークと複数ネットワークに
おけるサービスの両方がサポートされる。ローカルおよび複数ネットワークか
らなるトポロジの両方に対応し、IP ブロードキャストの使用に関わらず、処
理を行なうことを可能とするため、幾つかのノードタイプが定義されている。
この RFC では、NetBIOS over TCP パケットの詳細な仕様について定義すると
ともに、定数や変数についても定義している。より大枠の概要については、関
連する RFC の「TCP/UDP トランスポート上における NetBIOS サービスのため
のプロトコル標準: コンセプトと方式」を参照のこと。
NetBIOS Working Group [Page 1]
RFC 1002 March 1987
TABLE OF CONTENTS
1. STATUS OF THIS MEMO 4
2. 謝辞 4
3. はじめに 5
4. PACKET DESCRIPTIONS 5
4.1 名前のフォーマット 5
4.2 ネームサービスのパケット 7
4.2.1 ネームサービスのパケットの共通フォーマット 7
4.2.1.1 ヘッダ 8
4.2.1.2 問い合わせセクション 10
4.2.1.3 RESOURCE RECORD 11
4.2.2 名前登録リクエスト 13
4.2.3 名前上書きリクエストおよび要求 14
4.2.4 名前更新リクエスト 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. セッションサービスパケット 29
4.3.1 セッションサービスパケットの共通フォーマット 29
4.3.2 SESSION REQUEST パケット 30
4.3.3 POSITIVE SESSION RESPONSE パケット 31
4.3.4 NEGATIVE SESSION RESPONSE パケット 31
4.3.5 SESSION RETARGET RESPONSE パケット 31
4.3.6 SESSION MESSAGE パケット 32
4.3.7 SESSION KEEP ALIVE パケット 32
4.4 データグラムサービスパケット 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. プロトコルの詳細 35
5.1 NAME SERVICE PROTOCOLS 35
5.1.1 B ノードの動作 35
NetBIOS Working Group [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 データグラムサービスプロトコル 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. 定義済の定数と変数 83
参考 85
NetBIOS Working Group [Page 3]
RFC 1002 March 1987
TCP/UDP トランスポート上における
NetBIOS サービスのためのプロトコル標準:
詳細仕様
1. この記述のステータス
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]
RFC 1002 March 1987
3. はじめに
この RFC には、NetBIOS over TCP に関する詳細なパケットのフォーマッ
トやプロトコルの仕様が含まれている。この RFC は RFC 1001 「TCP/UDP
トランスポート上における NetBIOS サービスのためのプロトコル標準: コ
ンセプトと方式」[1] と関連するものである。
4. パケットの詳細
ビットおよびバイトの並ぶ順番については、「Assinged Numbers」[2] の最
新版で定義されている。
4.1. 名前のフォーマット
全ての NetBIOS パケット (ネームサービス、セッションサービス、データ
グラムサービス) で用いられている NetBIOS 名の表現形式は、RFC 883
[3] の Domain Name Service でいう「圧縮」された名前メッセージで定義
されている。このフォーマットは、「コンセプトと方式」側の「NetBIOS
名の表記法」というセクションでは、「第 2 レベルの表記法」と呼ばれて
いる。
記述の便を考慮し、RFC 883 の P.31 「Domain name representation and
compression」というセクションの先頭から 2 つのパラグラフを以下に転
載する:
ドメイン名のメッセージは、一連の「ラベル」列として表現される。
各ラベルは 1 オクテット長のフィールドの後に何オクテットかの
データが続いたものである。各ドメイン名は、ルートを示すヌルラベ
ルまで続くため、圧縮されたドメイン名は、ゼロ(0) の 1 バイトで
終了する。長さを示すフィールドの上位 2 ビットは 0 であることが
*必須*であり、残りの 6 ビットで 63 オクテット以下に制限された
ラベルの長さを示す。
実装を簡素化するため、ドメイン名を形成するラベルおよびラベルの
長さを示すフィールドを合わせた最大オクテット長は、255 オクテッ
ト以下に制限されている。
以下は、「FRED 」という NetBIOS 名の圧縮されていない表現形式である。
この名前は 4 つの ASCII 文字 F, R, E, D とそれに続く 12 文字の空白
文字 (0x20) からなる。この名前のスコープID は「NETBIOS.COM」である。
EGFCEFEECACACACACACACACACACACACA.NETBIOS.COM
この圧縮されていない名前の表現形式を「コンセプトおよび方式」の
「NetBIOS 名の表現形式」というセクションでは「第 1 レベルのエンコー
ディング」と呼ぶ。
以下はこの圧縮されていないドメイン名の圧縮した表記を図示したもので
ある。
NetBIOS Working Group [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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
ドメイン名の各セクションはラベル[7 (31ページ)] と呼ばれる。ラベルは
最長 63 バイトの長さである。圧縮された形式のラベルの最初のバイトは、
ラベルに含まれるバイト数である。上記の例では、先頭の 0x20 はもっと
も左のラベルであるドメイン名「EGFCEFEECACACACACACACACACACACACA」の
バイト数である。ラベルの長さを示すバイトに続くバイトは、ラベルの内
容となる文字そのものである。それ以降のラベルも最初のラベルと同様に、
エンコードされた NetBIOS 名が続き、最後は長さヌルを示す 0x00 で終了
する。長さゼロは、ルートのラベルを示し、これは常にヌルである。
ラベルの長さを示す箇所は実際には 6 ビット分のみが長さを示すフィール
ドとして使われる。フィールドの最上位 2 ビット、ビット 7 と 6 は上記
の圧縮された形式の例外(escape)を可能とするためのフラグである。ビッ
ト 7 と 6 の両方がセットされている場合 (11)、続く 14 ビットはこの名
前を構成する別のドメイン名の実際のラベルの文字列に対応する完全なメッ
セージを示すオフセットポインタとなる。このラベルのポインタにより、
パケット内でのドメイン名の更なる圧縮が可能となる。
NetBIOS の実装ではネームサービスのパケット中でのみラベル文字列への
ポインタを使うことができる。セッションサービスやデータグラムサービ
スのパケット中では用いることはできない。
NetBIOS Working Group [Page 6]
RFC 1002 March 1987
ラベルの長さを示すフィールドのビット 7 および 6 の、残り 2 つの値
(01 と 10) は RFC 883 [2 (ページ32)] によると将来の利用に備えて予約
されている。
圧縮された名前の最初のオクテットは、以下のビットパターンのいずれか
が含まれることが*必須*である (「x」は 0 または 1 の任意の値を保持す
るビットを示す):
00100000 - NetBIOS 名。長さは 32 (10進数)であることが*必須*
11xxxxxx - ラベル文字列へのポインタ
10xxxxxx - 予約
01xxxxxx - 予約
4.2. ネームサービスのパケット
4.2.1. ネームサービスのパケットの共通フォーマット
NetBIOS ネームサービスのパケットは、RFC 883 の Domain Name Service
(DNS) [7 (26-31 ページ)] で定義されたパケットの構造に準拠している。
この構造体は現存する DNS のパケットのフォーマットと互換性があるが、
NetBIOS 用のタイプやコードが追加されている。
ネームサービスのパケットが TCP コネクション上を送信される際は、その
ネームサービスのパケットの長さを示す、16 ビットの付号なし整数が先頭
に付けられる。
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]
RFC 1002 March 1987
4.2.1.1. ヘッダ
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
フィールド 説明
NAME_TRN_ID ネームサービスのトランザクションのトランザクションID
リクエスト側は、各トランザクション毎に一意な値を設
定する。レスポンス側は、レスポンスパケットの
NAME_TRN_ID に、リクエストパケット中の値を設定する。
OPCODE パケットのタイプを示すコード、以下の表を参照のこと
NM_FLAGS 処理を指定するフラグ、以下の表を参照のこと
RCODE リクエストの返却コード。各レスポンスパケットに対す
る RCODE の値の表は、以下を参照のこと。
QDCOUNT 名前の問い合わせセクション中に存在するエントリ数を
示す 16 ビット符合なし整数
サービスパケットの全レスポンスで、値は 0 であるが、
全ての NetBIOS 名リクエストにおいては 0 以外である。
ANCOUNT ネームサービスパケットの回答セクションに存在するリ
ソースレコード数を示す 16 ビットの符合なし整数
NSCOUNT ネームサービスパケットの権威セクションに存在するリ
ソースレコード数を示す 16 ビットの符合なし整数
NSCOUNT ネームサービスパケットの追加レコードセクションに存
在するリソースレコード数を示す 16 ビットの符合なし
整数
OPCODE フィールドは以下のように定義される:
0 1 2 3 4
+---+---+---+---+---+
| R | OPCODE |
+---+---+---+---+---+
NetBIOS Working Group [Page 8]
RFC 1002 March 1987
シンボル ビット 詳細
OPCODE 1-4 指定される処理:
0 = 問い合わせ(query)
5 = 登録(registration)
6 = 解放(release)
7 = WACK
8 = 更新(refresh)
R 0 レスポンスフラグ:
if bit == 0 then リクエストパケット
if bit == 1 then レスポンスパケット
NM_FLAGS フィールドは以下のように定義される:
0 1 2 3 4 5 6
+---+---+---+---+---+---+---+
|AA |TC |RD |RA | 0 | 0 | B |
+---+---+---+---+---+---+---+
シンボル ビット 詳細
B 6 ブロードキャストフラグ
= 1: パケットはブロードキャストかマルチキャスト
= 0: ユニキャスト
RA 3 再帰可能(Recursion Available)フラグ
NetBIOS ネームサーバからのレスポンスにおいての
み有効である。それ以外のレスポンスにおいては、0
にしなければならない。
1 の場合、NBNS は再帰問い合わせ、登録、解放をサ
ポートする
0 の場合、終端ノードが問い合わせや登録の試行を
繰り返す必要がある。
RD 2 再帰要求(Recursion Desired)フラグ
NetBIOS ネームサーバに対するリクエストにおいて
のみ設定することが可能である。
NBNS はレスポンスパケット中に再帰可否の設定を含
める。
1 の場合、NBNS が問い合わせ、登録、解放の処理の
再試行を行なう。
TC 1 切り詰め(Truncation)フラグ
NetBIOS Working Group [Page 9]
RFC 1002 March 1987
データグラムが 576 バイト以上の長さのため、メッ
セージが切り詰められている場合に設定される。
NetBIOS ネームサーバから情報を取得する際には
TCP を用いること。
AA 0 権威ある回答フラグ
OPCODE の R フラグが 0 の場合は、 0 に設定する
こと。
R フラグと AA フラグがともに 1 の場合、応答した
ノードはドメイン名に対して権威を持っているもの
として扱われる。
問い合わせに応答する終端ノードは、レスポンス中
のこのビットを常に設定する。
4.2.1.2. 問い合わせセクション
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
フィールド 説明
QUESTION_NAME 要求された NetBIOS 名の圧縮された形式
QUESTION_TYPE リクエストのタイプ。このフィールドの値はリクエスト
毎に設定される。
QUESTION_CLASS リクエストのクラス。このフィールドの値はリクエスト
毎に設定される。
QUESTION_TYPE は以下のように定義されている:
シンボル 値 説明:
NB 0x0020 NetBIOS の汎用ネームサービスのリソースレコード
NBSTAT 0x0021 NetBIOS の NODE STATUS リソースレコード(NODE
STATUS REQUEST を参照のこと)
QUESTION_CLASS は以下のように定義されている:
NetBIOS Working Group [Page 10]
RFC 1002 March 1987
シンボル 値 説明:
IN 0x0001 インターネットクラス(Internet class)
4.2.1.3. リソースレコード
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 /
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
フィールド 説明
RR_NAME このリソースレコードに対応する NetBIOS 名の圧縮さ
れた表現形式
RR_TYPE リソースレコードのタイプを示すコード
RR_CLASS リソースレコードのクラスを示すコード
TTL リソースレコード名の生存期間(Time To Live)
RDLENGTH RDATA フィールドのバイト数を示す符号なし 16 ビット
整数
RDATA RR_CLASS と RR_TYPE に依存したフィールド。NetBIOS
名に関するリソース情報を格納する
RESOURCE RECORD RR_TYPE フィールドの定義:
シンボル 値 説明:
A 0x0001 IP アドレスを示すリソースレコード(REDIRECT NAME
QUERY RESPONSE を参照のこと)
NS 0x0002 ネームサーバを示すリソースレコード(REDIRECT
NetBIOS Working Group [Page 11]
RFC 1002 March 1987
NAME QUERY RESPONSE を参照のこと)
NULL 0x000A NULL リソースレコード (WAIT FOR ACKNOWLEDGEMENT
RESPONSE を参照のこと)
NB 0x0020 NetBIOS の汎用ネームサービスを示すリソースレコー
ド(以下の NB_FLAGS と NB_ADDRESS を参照のこと)
NBSTAT 0x0021 NetBIOS NODE STATUS リソースレコード (NODE
STATUS RESPONSE を参照のこと)
RESOURCE RECORD RR_CLASS フィールドの定義:
シンボル 値 説明:
IN 0x0001 Internet class
RR_TYPE が「NB」の場合の RESOURCE RECORD RDATA フィールドに格納され
る NB_FLAGS:
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 |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
シンボル ビット 説明:
RESERVED 3-15 将来の使用のため予約。0 であることが*必須*
ONT 1,2 所有者のノードタイプ:
00 = B ノード
01 = P ノード
10 = M ノード
11 = 将来の使用のため予約
登録リクエストの場合、これは要求側のノードタイ
プである
レスポンスの場合、これは実際の所有者のノードタ
イプである。
G 0 グループ名フラグ
1 の場合、RR_NAME は NetBIOS グループ名である
0 の場合、RR_NAME は NetBIOS ユニーク名である
RR_TYPE が「NB」の場合の RESOURCE RECORD RDATA フィールドに格納され
る NB_ADDRESS フィールドは、名前の所有者の IP アドレスである
NetBIOS Working Group [Page 12]
RFC 1002 March 1987
4.2.2. 名前登録リクエスト
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
RR_NAME は QUESTION_NAME と同一であるため、データグラム長を最大の
576 以下に押えるために、RR_NAME の表記は QUESTION_NAME の名前のラベ
ルへのポインタとすることが*必須*である。圧縮した名前のラベルへのポ
インタについての詳細は、前述した DNS 名のフォーマットについてのセク
ションや、RFC 833 Domain Names - Implementation and Specification
の 31、32 ページを参照のこと。
NetBIOS Working Group [Page 13]
RFC 1002 March 1987
4.2.3. 名前上書きリクエストおよび要求
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x0000 | 0x0001 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
/ QUESTION_NAME /
/ /
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NB (0x0020) | IN (0x0001) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
/ RR_NAME /
/ /
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NB (0x0020) | IN (0x0001) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x0006 | NB_FLAGS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NB_ADDRESS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
NetBIOS Working Group [Page 14]
RFC 1002 March 1987
4.2.4. 名前更新リクエスト
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| 0x9 |0|0|0|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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
NetBIOS Working Group [Page 15]
RFC 1002 March 1987
4.2.5. 名前登録肯定レスポンス
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 |1| 0x5 |1|0|1|1|0 0|0| 0x0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x0000 | 0x0001 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x0000 | 0x0000 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
/ RR_NAME /
/ /
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NB (0x0020) | IN (0x0001) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x0006 | NB_FLAGS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NB_ADDRESS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4.2.6. 名前登録否定レスポンス
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 |1| 0x5 |1|0|1|1|0 0|0| RCODE |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x0000 | 0x0001 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x0000 | 0x0000 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
/ RR_NAME /
/ /
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NB (0x0020) | IN (0x0001) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x0006 | NB_FLAGS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NB_ADDRESS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
NetBIOS Working Group [Page 16]
RFC 1002 March 1987
RCODE フィールドの値は以下のとおり:
シンボル 値 説明:
FMT_ERR 0x1 フォーマットエラー(Format Error)。リクエストの
形式が不正である
SRV_ERR 0x2 サーバ側の不正処理(Server failure)。NBNS に問題
があり、名前の処理が行なえない
IMP_ERR 0x4 サポートされていないリクエストによるエラー。更
Unsupported request error. Allowable only
for challenging NBNS when gets an Update type
registration request.
RFS_ERR 0x5 拒否エラー。ポリシー上の問題でサーバがそのホス
トからの名前登録を受け付けない。
ACT_ERR 0x6 アクティブエラー。名前は別のノードによって所有
されている
CFT_ERR 0x7 名前競合エラー。ユニーク名は、別のノードによっ
て所有されている。
-1
4.2.7. END-NODE CHALLENGE REGISTRATION RESPONSE
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 |1| 0x5 |1|0|1|0|0 0|0| 0x0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x0000 | 0x0001 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x0000 | 0x0000 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
/ RR_NAME /
/ /
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NB (0x0020) | IN (0x0001) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x0006 | NB_FLAGS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NB_ADDRESS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
NetBIOS Working Group [Page 17]
RFC 1002 March 1987
4.2.8. NAME CONFLICT 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 |1| 0x5 |1|0|1|1|0 0|0| 0x7 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x0000 | 0x0001 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x0000 | 0x0000 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
/ RR_NAME /
/ /
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NB (0x0020) | IN (0x0001) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x00000000 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x0006 |0|ONT|0| 0x000 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x00000000 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This packet is identical to a NEGATIVE NAME REGISTRATION RESPONSE
with RCODE = CFT_ERR.
NetBIOS Working Group [Page 18]
RFC 1002 March 1987
4.2.9. 名前解放リクエスト & 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| 0x6 |0|0|0|0|0 0|B| 0x0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x0001 | 0x0000 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x0000 | 0x0001 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
/ QUESTION_NAME /
/ /
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NB (0x0020) | IN (0x0001) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
/ RR_NAME /
/ /
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NB (0x0020) | IN (0x0001) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x00000000 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x0006 | NB_FLAGS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NB_ADDRESS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Since the RR_NAME is the same name as the QUESTION_NAME, the
RR_NAME representation must use label string pointers to the
QUESTION_NAME labels to guarantee the length of the datagram is
less than the maximum 576 bytes. This is the same condition as
with the NAME REGISTRATION REQUEST.
NetBIOS Working Group [Page 19]
RFC 1002 March 1987
4.2.10. POSITIVE NAME RELEASE RESPONSE
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 |1| 0x6 |1|0|0|0|0 0|0| 0x0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x0000 | 0x0001 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x0000 | 0x0000 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
/ RR_NAME /
/ /
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NB (0x0020) | IN (0x0001) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x0006 | NB_FLAGS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NB_ADDRESS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4.2.11. NEGATIVE NAME RELEASE RESPONSE
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 |1| 0x6 |1|0|0|0|0 0|0| RCODE |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x0000 | 0x0001 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x0000 | 0x0000 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
/ RR_NAME /
/ /
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NB (0x0020) | IN (0x0001) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x0006 | NB_FLAGS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NB_ADDRESS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
NetBIOS Working Group [Page 20]
RFC 1002 March 1987
RCODE フィールドの値:
シンボル 値 説明:
FMT_ERR 0x1 フォーマットエラー(Format Error)。リクエストの
形式が不正である
SRV_ERR 0x2 サーバ側の不正処理(Server failure)。NBNS に問題
があり、名前の処理が行なえない
RFS_ERR 0x5 拒否エラー。ポリシー上の問題でサーバがそのホス
トからの名前登録を受け付けない。
ACT_ERR 0x6 アクティブエラー。名前は別のノードによって所有
されており、そのノードだけが解放することができ
る。NetBIOS ネームサーバはあるノードに対して、
ノードが所有していない名前を解放するさせること
ができる場合もある。これにより通知なく停止した
ノードが所有する有効でない名前の検知が可能になる。
4.2.12. NAME QUERY 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| 0x0 |0|0|1|0|0 0|B| 0x0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x0001 | 0x0000 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x0000 | 0x0000 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
/ QUESTION_NAME /
/ /
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NB (0x0020) | IN (0x0001) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
NetBIOS Working Group [Page 21]
RFC 1002 March 1987
4.2.13. POSITIVE NAME QUERY RESPONSE
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 |1| 0x0 |1|T|1|?|0 0|0| 0x0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x0000 | 0x0001 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x0000 | 0x0000 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
/ RR_NAME /
/ /
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NB (0x0020) | IN (0x0001) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RDLENGTH | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
/ ADDR_ENTRY ARRAY /
/ /
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
ADDR_ENTRY ARRAY は 0 個以上の ADDR_ENTRY レコードの配列である。
各 ADDR_ENTRY レコードは名前の所有者を示す。グループ名の場合は複数
のエントリが存在することがある。ただし、パケットサイズの制限のため、
名前のリストが不完全な場合がある。この場合、データの切り詰めを示す
ためにビット22「T」が設定される。
各 ADDR_ENTRY は、以下のような形式である:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NB_FLAGS | NB_ADDRESS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NB_ADDRESS (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
NetBIOS Working Group [Page 22]
RFC 1002 March 1987
4.2.14. NEGATIVE NAME QUERY RESPONSE
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 |1| 0x0 |1|0|1|?|0 0|0| RCODE |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x0000 | 0x0000 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x0000 | 0x0000 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
/ RR_NAME /
/ /
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NULL (0x000A) | IN (0x0001) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x00000000 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x0000 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
RCODE フィールドの値は以下のとおり:
シンボル 値 説明
FMT_ERR 0x1 フォーマットエラー(Format Error)。リクエストの
形式が不正である
SRV_ERR 0x2 サーバ側の不正処理(Server failure)。NBNS に問題
があり、名前の処理が行なえない
NAM_ERR 0x3 名前エラー(Name Error)。要求された名前は存在し
ない。
IMP_ERR 0x4 サポートされていないリクエストによるエラー
(Unsupported request error)。更
Allowable only for challenging NBNS when gets
an Update type registration request.
-1
RFS_ERR 0x5 拒否エラー。ポリシー上の問題でサーバがそのホス
トからの名前登録を受け付けない。
NetBIOS Working Group [Page 23]
RFC 1002 March 1987
4.2.15. REDIRECT NAME QUERY RESPONSE
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 |1| 0x0 |0|0|1|0|0 0|0| 0x0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x0000 | 0x0000 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x0001 | 0x0001 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
/ RR_NAME /
/ /
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NS (0x0002) | IN (0x0001) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RDLENGTH | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
/ NSD_NAME /
/ /
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
/ RR_NAME /
/ /
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| A (0x0001) | IN (0x0001) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x0004 | NSD_IP_ADDR |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NSD_IP_ADDR, continued |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
NAME QUERY REQUEST に応答する終端ノードは、NEGATIVE および POSITIVE
両方の NAME QUERY RESPONSE パケットにおいて、AA と RA の両方のビッ
トを常に設定する。終端ノードが REDIRECT NAME QUERY RESPONSE パケッ
トを送信することは決してない。
NetBIOS Working Group [Page 24]
RFC 1002 March 1987
要求側が REDIRECT NAME QUERY RESPONSE を受信した場合は、
When the requestor receives the REDIRECT NAME QUERY RESPONSE it
must reiterate the NAME QUERY REQUEST to the NBNS specified by
the NSD_IP_ADDR field of the A type RESOURCE RECORD in the
ADDITIONAL section of the response packet. This is an optional
packet for the NBNS.
6
The NSD_NAME and the RR_NAME in the ADDITIONAL section of the
response packet are the same name. Space can be optimized if
label string pointers are used in the RR_NAME which point to the
labels in the NSD_NAME.
The RR_NAME in the AUTHORITY section is the name of the domain
the NBNS called by NSD_NAME has authority over.
4.2.16. WAIT FOR ACKNOWLEDGEMENT (WACK) RESPONSE
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 |1| 0x7 |1|0|0|0|0 0|0| 0x0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x0000 | 0x0001 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x0000 | 0x0000 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
/ RR_NAME /
/ /
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NULL (0x0020) | IN (0x0001) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x0002 | OPCODE | NM_FLAGS | 0x0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
NetBIOS Working Group [Page 25]
RFC 1002 March 1987
The NAME_TRN_ID of the WACK RESPONSE packet is the same
NAME_TRN_ID of the request that the NBNS is telling the requestor
to wait longer to complete. The RR_NAME is the name from the
request, if any. If no name is available from the request then
it is a null name, single byte of zero.
The TTL field of the ResourceRecord is the new time to wait, in
seconds, for the request to complete. The RDATA field contains
the OPCODE and NM_FLAGS of the request.
A TTL value of 0 means that the NBNS can not estimate the time it
may take to complete a response.
4.2.17. NODE STATUS 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| 0x0 |0|0|0|0|0 0|B| 0x0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x0001 | 0x0000 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x0000 | 0x0000 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
/ QUESTION_NAME /
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NBSTAT (0x0021) | IN (0x0001) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
NetBIOS Working Group [Page 26]
RFC 1002 March 1987
4.2.18. NODE STATUS RESPONSE
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 |1| 0x0 |1|0|0|0|0 0|0| 0x0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x0000 | 0x0001 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x0000 | 0x0000 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
/ RR_NAME /
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NBSTAT (0x0021) | IN (0x0001) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x00000000 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RDLENGTH | NUM_NAMES | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
+ +
/ NODE_NAME ARRAY /
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
/ STATISTICS /
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
NODE_NAME 配列は 0 以上の NUM_NAMES 個の NODE_NAME レコードのエント
リの配列である。各 NODE_NAME エントリには、応答側のローカルネームテー
ブルに存在する要求側と同じ NetBIOS スコープにある有効な名前が格納さ
れている。RR_NAME は要求された名前である。
NetBIOS Working Group [Page 27]
RFC 1002 March 1987
NODE_NAME エントリ:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+--- ---+
| |
+--- NETBIOS FORMAT NAME ---+
| |
+--- ---+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NAME_FLAGS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
NAME_FLAGS フィールドは以下のとおり:
1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| G | ONT |DRG|CNF|ACT|PRM| RESERVED |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
NAME_FLAGS フィールドは以下のように定義されている:
シンボル ビット 説明:
RESERVED 7-15 将来の使用のため予約。0 であることが*必須*
PRM 6 永続名(Permanent Name)フラグ。エントリが永続ノー
ド名の場合は 1 にする。それ以外の名前の場合は、
0 にする。
ACT 5 有効名(Active Name)フラグ。すべてのエントリは、
このフラグを 1 に設定する必要がある。
CNF 4 競合フラグ。1 の場合、このノード上で名前が競合
状態にある。
DRG 3 登録解除中フラグ。1 の場合、この名前は削除中で
ある。
ONT 1,2 所有者のノードタイプ:
00 = B ノード
01 = P ノード
10 = M ノード
11 = 将来の使用のため予約
G 0 グループ名フラグ
1 の場合、名前は NetBIOS グループ名である
0 の場合、名前は NetBIOS ユニーク名である
NetBIOS Working Group [Page 28]
RFC 1002 March 1987
STATISTICS Field of the NODE STATUS RESPONSE:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| UNIT_ID (Unique unit ID) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| UNIT_ID,continued | JUMPERS | TEST_RESULT |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VERSION_NUMBER | PERIOD_OF_STATISTICS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NUMBER_OF_CRCs | NUMBER_ALIGNMENT_ERRORS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NUMBER_OF_COLLISIONS | NUMBER_SEND_ABORTS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NUMBER_GOOD_SENDS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NUMBER_GOOD_RECEIVES |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NUMBER_RETRANSMITS | NUMBER_NO_RESOURCE_CONDITIONS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NUMBER_FREE_COMMAND_BLOCKS | TOTAL_NUMBER_COMMAND_BLOCKS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|MAX_TOTAL_NUMBER_COMMAND_BLOCKS| NUMBER_PENDING_SESSIONS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAX_NUMBER_PENDING_SESSIONS | MAX_TOTAL_SESSIONS_POSSIBLE |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SESSION_DATA_PACKET_SIZE |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4.3. セッションサービスパケット
4.3.1. セッションサービスパケットの共通フォーマット
すべてのセッションサービスのメッセージは TCP コネクション上で送信さ
れる。
すべてのセッションパケットは以下のような共通の構造をもつ:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TYPE | FLAGS | LENGTH |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
/ TRAILER (パケットタイプ依存) /
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
TYPE, FLAGS, LENGTH フィールドは、各セッションパケット中に存在する。
NetBIOS Working Group [Page 29]
RFC 1002 March 1987
LENGTH フィールドには LENGTH フィールドに続くデータのバイト数が格納
される。言い替えると LENGTH とは TRAILER フィールドのサイズである。
POSITIVE SESSION RESPONSE パケットの場合、これは常に 0 であり、
RETARGET SESSION RESPONSE パケットの場合は 6 となる。
FLAGS フィールドのビットの 1 つは、LENGTH フィールドの高位ビットと
して機能する。これにより、TRAILER フィールドの長さは 0 から 128K バ
イトの範囲をとる。
セッションパケットタイプ (16進数):
00 - SESSION MESSAGE
81 - SESSION REQUEST
82 - POSITIVE SESSION RESPONSE
83 - NEGATIVE SESSION RESPONSE
84 - RETARGET SESSION RESPONSE
85 - SESSION KEEP ALIVE
FLAGS フィールドの各ビットの定義:
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| 0 | 0 | 0 | 0 | 0 | 0 | 0 | E |
+---+---+---+---+---+---+---+---+
シンボル ビット 説明
E 7 LENGTH フィールドの拡張。LENGTH フィールドの最
上位ビットとして用いられる。
RESERVED 0-6 予約。 0 であることが*必須*である。
4.3.2. SESSION 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TYPE | FLAGS | LENGTH |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
/ CALLED NAME /
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
/ CALLING NAME /
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
NetBIOS Working Group [Page 30]
RFC 1002 March 1987
4.3.3. POSITIVE SESSION RESPONSE パケット
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TYPE | FLAGS | LENGTH |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4.3.4. NEGATIVE SESSION RESPONSE パケット
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TYPE | FLAGS | LENGTH |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ERROR_CODE |
+-+-+-+-+-+-+-+-+
NEGATIVE SESSION RESPONSE パケットのエラーコードの値(16進数)を以下
に示す:
80 - Not listening on called name
81 - Not listening for calling name
82 - Called name not present
83 - Called name present, but insufficient resources
8F - 特定できないエラー
4.3.5. SESSION RETARGET RESPONSE パケット
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TYPE | FLAGS | LENGTH |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RETARGET_IP_ADDRESS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PORT |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
NetBIOS Working Group [Page 31]
RFC 1002 March 1987
4.3.6. SESSION MESSAGE パケット
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TYPE | FLAGS | LENGTH |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
/ /
/ USER_DATA /
/ /
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4.3.7. SESSION KEEP ALIVE パケット
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TYPE | FLAGS | LENGTH |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4.4. データグラムサービスパケット
4.4.1. NetBIOS データグラムヘッダ
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MSG_TYPE | FLAGS | DGM_ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SOURCE_IP |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SOURCE_PORT | DGM_LENGTH |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PACKET_OFFSET |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
MSG_TYPE の値(16進数):
10 - DIRECT_UNIQUE DATAGRAM
11 - DIRECT_GROUP DATAGRAM
12 - BROADCAST DATAGRAM
13 - DATAGRAM ERROR
14 - DATAGRAM QUERY REQUEST
15 - DATAGRAM POSITIVE QUERY RESPONSE
16 - DATAGRAM NEGATIVE QUERY RESPONSE
NetBIOS Working Group [Page 32]
RFC 1002 March 1987
FLAGS フィールドの各ビットの定義:
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| 0 | 0 | 0 | 0 | SNT | F | M |
+---+---+---+---+---+---+---+---+
シンボル ビット 説明
M 7 MORE フラグ。このフラグが設定されている場合、
NetBIOS データグラムのフラグメントが後続する。
F 6 FIRST パケットフラグ。このフラグが設定されてい
る場合、これが NetBIOS データグラムの最初の(も
しくは唯一の)フラグメントである。
SNT 4,5 Source 終端ノードタイプ:
00 = B ノード
01 = P ノード
10 = M ノード
11 = NBDD
RESERVED 0-3 予約。0 であることが*必須*である。
4.4.2. DIRECT_UNIQUE, DIRECT_GROUP, BROADCAST データグラム
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MSG_TYPE | FLAGS | DGM_ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SOURCE_IP |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SOURCE_PORT | DGM_LENGTH |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PACKET_OFFSET | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
/ SOURCE_NAME /
/ /
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
/ DESTINATION_NAME /
/ /
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
/ USER_DATA /
/ /
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
NetBIOS Working Group [Page 33]
RFC 1002 March 1987
4.4.3. DATAGRAM ERROR 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MSG_TYPE | FLAGS | DGM_ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SOURCE_IP |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SOURCE_PORT | ERROR_CODE |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
ERROR_CODE の値(16進数):
82 - DESTINATION NAME NOT PRESENT
83 - INVALID SOURCE NAME FORMAT
84 - INVALID DESTINATION NAME FORMAT
4.4.4. DATAGRAM QUERY 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MSG_TYPE | FLAGS | DGM_ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SOURCE_IP |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SOURCE_PORT | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
/ DESTINATION_NAME /
/ /
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4.4.5. DATAGRAM POSITIVE AND NEGATIVE QUERY RESPONSE
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MSG_TYPE | FLAGS | DGM_ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SOURCE_IP |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SOURCE_PORT | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
/ DESTINATION_NAME /
/ /
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
NetBIOS Working Group [Page 34]
RFC 1002 March 1987
5. プロトコルの詳細
5.1. ネームサービスプロトコル
REQUEST パケットは常に well-known の UDP ポートである
NAME_SERVICE_UDP_PORT に対して送信される。宛先アドレスは通常 IP ブ
ロードキャストアドレスか、初期化時に設定された NBNS の IP アドレス
である。稀なケースとして、リクエストパケットが終端ノードに対して送
信されることもある。例えば NAME QUERY REQUEST がノードに対する「チャ
レンジ」として送信される場合である。
RESPONSE パケットは常に REQUEST パケットの送信元 IP アドレスおよび
送信元 UDP ポートに対して送信される。
DEMAND パケットは常に well-known の UDP ポートである
NAME_SERVICE_UDP_PORT に対して送信される。宛先の IP アドレスに関す
る制約はない。
このセクションで用いる用語について:
tid - トランザクションID。これは要求側の IP アドレスとト
ランザクションの作成元によって生成された一意な 16
ビットの値から生成される値である。
5.1.1. B ノードの動作
5.1.1.1. B ノードの ADD NAME
PROCEDURE add_name(newname)
/*
* B ノードのホストの初期化
*/
BEGIN
REPEAT
/* ネームサービスパケットの生成 */
ONT = B_NODE; /* ブロードキャスト(B)ノード */
G = UNIQUE; /* ユニーク名 */
TTL = 0;
NAME REGISTRATION REQUEST パケットのブロードキャスト;
/*
* リモートのノードは必要な場合レスポンスパケットを送出す
* る
*/
NetBIOS Working Group [Page 35]
RFC 1002 March 1987
pause(BCAST_REQ_RETRY_TIMEOUT);
UNTIL レスポンスパケットが到着するか、再送カウントを超過するま
で
IF レスポンスパケットが到着しなかった THEN
BEGIN /* レスポンスなし */
/*
* パケットの生成
*/
ONT = B_NODE; /* ブロードキャストノード */
G = UNIQUE; /* ユニーク名 */
TTL = 0;
/*
* 他のノードにこの名前を保持していることを通知
*/
NAME UPDATE REQUEST パケットのブロードキャスト;
/* 名前をローカルネームテーブルに追加 */
return success;
END /* レスポンスなし */
ELSE
BEGIN /* レスポンスあり */
/*
* 応答中のトランザクションID(tid)がリクエストとして送信
* されたtidと合致するか
*/
IF NOT レスポンスtid = リクエストtid THEN
BEGIN
レスポンスパケットを無視;
END
ELSE
CASE パケットタイプ OF
NEGATIVE NAME REGISTRATION RESPONSE:
return 失敗; /* 名前は登録できない */
POSITIVE NAME REGISTRATION RESPONSE:
END-NODE CHALLENGE NAME REGISTRATION RESPONSE:
/*
* B ノードは通常これらのレスポンスを受信しない
*
*/
パケットを無視;
NetBIOS Working Group [Page 36]
RFC 1002 March 1987
END /* case */;
END /* レスポンスあり */
END /* procedure */
5.1.1.2. B ノードの ADD_GROUP NAME
PROCEDURE add_group_name(newname)
/*
* B ノードのホストの初期化処理
*/
BEGIN
/*
* グループ名ビット(B)がリクエストパケット中に
* 必ず設定されることを除けば、ユニーク名と同じ
*
*/
...
G = GROUP;
...
...
/*
* リクエストのブロードキャスト ...
*/
END
5.1.1.3. B ノードの FIND_NAME
PROCEDURE find_name(name)
/*
* B ノードのホストの初期化処理
*/
BEGIN
REPEAT
/*
* パケットの生成
*/
ONT = B;
TTL = 0;
G = DONT CARE;
NAME QUERY REQUEST パケットのブロードキャスト;
NetBIOS Working Group [Page 37]
RFC 1002 March 1987
/*
* レスポンスパケットを送信するノードがあるかも知れない
*/
pause(BCAST_REQ_RETRY_TIMEOUT);
UNTIL レスポンスパケットの受信 OR
max transmit threshold exceeded
IF レスポンスパケットが受信できない THEN
return 失敗;
ELSE
IF NOT レスポンスtid = リクエストtid THEN
パケットを無視;
ELSE
CASE パケットタイプ OF
POSITIVE NAME QUERY RESPONSE:
/*
* 競合状態検出のためのタイマ開始
*
* Be prepared to detect conflict if
* any more response packets are received.
*
*/
save response as authoritative response;
start_timer(CONFLICT_TIMER);
return 成功;
NEGATIVE NAME QUERY RESPONSE:
REDIRECT NAME QUERY RESPONSE:
/*
* B ノードは通常これらのレスポンスを受信しない
*
*/
レスポンスパケットを無視;
END /* case */
END /* procedure */
5.1.1.4. B ノードの NAME RELEASE
PROCEDURE delete_name (name)
BEGIN
REPEAT
/*
* パケット生成
*/
NetBIOS Working Group [Page 38]
RFC 1002 March 1987
...
/*
* リクエストの送信
*/
NAME RELEASE REQUEST パケットのブロードキャスト;
/*
* レスポンスパケットはない筈である
*/
pause(BCAST_REQ_RETRY_TIMEOUT);
UNTIL 再送カウントを超過するまで
END /* procedure */
5.1.1.5. B ノードの受信パケット処理
以下の処理は NAME_SERVICE_UDP_PORT にブロードキャストもしくはユニキャ
ストのパケットが受信した際に行なわれる。
PROCEDURE process_incoming_packet(packet)
/*
* B ノードに対する受信パケットの処理の初期化
*/
BEGIN
/*
* 注意: レスポンスパケットは常に
* to: リクエストパケットの送信元 IP アドレス
* リクエストパケットの送信元 UDP ポート
* に送信される
*/
CASE パケットタイプ OF
NAME REGISTRATION REQUEST (UNIQUE):
IF 名前がローカルネームテーブルに存在する THEN
NEGATIVE NAME REGISTRATION RESPONSE を送信;
NAME REGISTRATION REQUEST (GROUP):
IF 名前がローカルネームテーブルに存在する THEN
BEGIN
IF ローカルエントリがユニーク名 THEN
NEGATIVE NAME REGISTRATION RESPONSE を送信;
END
NAME QUERY REQUEST:
IF 名前がローカルネームテーブルに存在する THEN
BEGIN
レスポンスパケット生成;
NetBIOS Working Group [Page 39]
RFC 1002 March 1987
POSITIVE NAME QUERY RESPONSE を送信;
POSITIVE NAME QUERY RESPONSE:
IF name conflict timer is not active THEN
BEGIN
/*
* timer has expired already... ignore this
* packet
*/
return;
END
ELSE /* timer is active */
IF a response for this name has previously been
received THEN
BEGIN /* existing entry */
/*
* we sent out a request packet, and
* have already received (at least)
* one response
*
* Check if conflict exists.
* If so, send out a conflict packet.
*
* Note: detecting conflict does NOT
* affect any existing sessions.
*
*/
/*
* Check for name conflict.
* See "Name Conflict" in Concepts and Methods
*/
check saved authoritative response against
information in this response packet;
IF conflict detected THEN
BEGIN
unicast NAME CONFLICT DEMAND packet;
IF entry exists in cache THEN
BEGIN
remove entry from cache;
END
END
END /* existing entry */
ELSE
BEGIN
/*
* Note: If this was the first response
* to a name query, it would have been
* handled in the
* find_name() procedure.
NetBIOS Working Group [Page 40]
RFC 1002 March 1987
*/
ignore packet;
END
NAME CONFLICT DEMAND:
IF name exists in local name table THEN
BEGIN
mark name as conflict detected;
/*
* a name in the state "conflict detected"
* does not "logically" exist on that node.
* No further session will be accepted on
* that name.
* No datagrams can be sent against that name.
* Such an entry will not be used for
* purposes of processing incoming request
* packets.
* The only valid user NetBIOS operation
* against such a name is DELETE NAME.
*/
END
NAME RELEASE REQUEST:
IF caching is being done THEN
BEGIN
remove entry from cache;
END
NAME UPDATE REQUEST:
IF caching is being done THEN
BEGIN
IF entry exists in cache already,
update cache;
ELSE IF name is "interesting" THEN
BEGIN
add entry to cache;
END
END
NODE STATUS REQUEST:
IF name exists in local name table THEN
BEGIN
/*
* send only those names that are
* in the same scope as the scope
* field in the request packet
*/
send NODE STATUS RESPONSE;
END
END
NetBIOS Working Group [Page 41]
RFC 1002 March 1987
5.1.2. P ノードの動作
P ノードが送受信するパケットはすべてユニキャストの UDP パケットであ
る。P ノードはネームサービスの要求を、P ノードの設定により指定され
た NBNS ノードに対して送信する。
5.1.2.1. P ノードの ADD_NAME
PROCEDURE add_name(newname)
/*
* P ノードのホスト初期化処理
*/
BEGIN
REPEAT
/*
* パケット生成
*/
ONT = P;
G = UNIQUE;
...
/*
* リクエスト送信
*/
NAME REGISTRATION REQUEST パケットのユニキャスト送信;
/*
* NBNS がレスポンスパケットを送信する
*/
IF WACK RESPONSE を受信 THEN
pause(レスポンスパケットの TTL フィールドの時間);
ELSE
pause(UCAST_REQ_RETRY_TIMEOUT);
UNTIL レスポンスパケットが受信された OR
再送カウントを超過した
IF レスポンスパケットを受信できなかった THEN
BEGIN /* レスポンスなし */
/*
* NBNS が停止。名前の要求ができない。
*/
return 失敗; /* 名前の要求はできない */
END /* レスポンスなし */
ELSE
NetBIOS Working Group [Page 42]
RFC 1002 March 1987
BEGIN /* レスポンスあり */
IF NOT response tid = request tid THEN
BEGIN
/* Packet may belong to another transaction */
ignore response packet;
END
ELSE
CASE packet type OF
POSITIVE NAME REGISTRATION RESPONSE:
/*
* name can be added
*/
adjust refresh timeout value, TTL, for this name;
return success; /* name can be added */
NEGATIVE NAME REGISTRATION RESPONSE:
return failure; /* name cannot be added */
END-NODE CHALLENGE REGISTRATION REQUEST:
BEGIN /* end node challenge */
/*
* The response packet has in it the
* address of the presumed owner of the
* name. Challenge that owner.
* If owner either does not
* respond or indicates that he no longer
* owns the name, claim the name.
* Otherwise, the name cannot be claimed.
*
*/
REPEAT
/*
* build packet
*/
...
unicast NAME QUERY REQUEST packet to the
address contained in the END NODE
CHALLENGE RESPONSE packet;
/*
* remote node may send response packet
*/
pause(UCAST_REQ_RETRY_TIMEOUT);
NetBIOS Working Group [Page 43]
RFC 1002 March 1987
UNTIL response packet is received or
retransmit count has been exceeded
IF no response packet is received OR
NEGATIVE NAME QUERY RESPONSE packet
received THEN
BEGIN /* update */
/*
* name can be claimed
*/
REPEAT
/*
* build packet
*/
...
unicast NAME UPDATE REQUEST to NBNS;
/*
* NBNS node will send response packet
*/
IF receive a WACK RESPONSE THEN
pause(time from TTL field of response);
ELSE
pause(UCAST_REQ_RETRY_TIMEOUT);
UNTIL response packet is received or
retransmit count has been exceeded
IF no response packet received THEN
BEGIN /* no response */
/*
* name could not be claimed
*/
return failure;
END /* no response */
ELSE
CASE packet type OF
POSITIVE NAME REGISTRATION RESPONSE:
/*
* add name
*/
return success;
NEGATIVE NAME REGISTRATION RESPONSE:
/*
* you lose ...
*/
NetBIOS Working Group [Page 44]
RFC 1002 March 1987
return failure;
END /* case */
END /* update */
ELSE
/*
* received a positive response to the "challenge"
* Remote node still has name
*/
return failure;
END /* end node challenge */
END /* response */
END /* procedure */
5.1.2.2. P-NODE ADD GROUP NAME
PROCEDURE add_group_name(newname)
/*
* Host initiated processing for a P node
*/
BEGIN
/*
* same as for a unique name, except that the
* request packet must indicate that a
* group name claim is being made.
*/
...
G = GROUP;
...
/*
* send packet
*/
...
END
5.1.2.3. P-NODE FIND NAME
PROCEDURE find_name(name)
/*
* Host initiated processing for a P node
*/
BEGIN
NetBIOS Working Group [Page 45]
RFC 1002 March 1987
REPEAT
/*
* build packet
*/
ONT = P;
G = DONT CARE;
unicast NAME QUERY REQUEST packet;
/*
* a NBNS node might send response packet
*/
IF receive a WACK RESPONSE THEN
pause(time from TTL field of response);
ELSE
pause(UCAST_REQ_RETRY_TIMEOUT);
UNTIL response packet received OR
max transmit threshold exceeded
IF no response packet received THEN
return failure;
ELSE
IF NOT response tid = request tid THEN
ignore packet;
ELSE
CASE packet type OF
POSITIVE NAME QUERY RESPONSE:
return success;
REDIRECT NAME QUERY RESPONSE:
/*
* NBNS node wants this end node
* to use some other NBNS node
* to resolve the query.
*/
repeat query with NBNS address
in the response packet;
NEGATIVE NAME QUERY RESPONSE:
return failure;
END /* case */
END /* procedure */
5.1.2.4. P-NODE DELETE_NAME
PROCEDURE delete_name (name)
NetBIOS Working Group [Page 46]
RFC 1002 March 1987
/*
* Host initiated processing for a P node
*/
BEGIN
REPEAT
/*
* build packet
*/
...
/*
* send request
*/
unicast NAME RELEASE REQUEST packet;
IF receive a WACK RESPONSE THEN
pause(time from TTL field of response);
ELSE
pause(UCAST_REQ_RETRY_TIMEOUT);
UNTIL retransmit count has been exceeded
or response been received
IF response has been received THEN
CASE packet type OF
POSITIVE NAME RELEASE RESPONSE:
return success;
NEGATIVE NAME RELEASE RESPONSE:
/*
* NBNS does want node to delete this
* name !!!
*/
return failure;
END /* case */
END /* procedure */
5.1.2.5. P-NODE INCOMING PACKET PROCESSING
Processing initiated by reception of packets at a P node
PROCEDURE process_incoming_packet(packet)
/*
* Processing initiated by incoming packets at a P node
*/
BEGIN
NetBIOS Working Group [Page 47]
RFC 1002 March 1987
/*
* always ignore UDP broadcast packets
*/
IF packet was sent as a broadcast THEN
BEGIN
ignore packet;
return;
END
CASE packet type of
NAME CONFLICT DEMAND:
IF name exists in local name table THEN
mark name as in conflict;
return;
NAME QUERY REQUEST:
IF name exists in local name table THEN
BEGIN /* name exists */
/*
* build packet
*/
...
/*
* send response to the IP address and port
* number from which the request was received.
*/
send POSITIVE NAME QUERY RESPONSE ;
return;
END /* exists */
ELSE
BEGIN /* does not exist */
/*
* send response to the requestor
*/
send NEGATIVE NAME QUERY RESPONSE ;
return;
END /* does not exist */
NODE STATUS REQUEST:
/*
* Name of "*" may be used for force node to
* divulge status for administrative purposes
*/
IF name in local name table OR name = "*" THEN
BEGIN
/*
NetBIOS Working Group [Page 48]
RFC 1002 March 1987
* Build response packet and
* send to requestor node
* Send only those names that are
* in the same scope as the scope
* in the request packet.
*/
send NODE STATUS RESPONSE;
END
NAME RELEASE REQUEST:
/*
* This will be received if the NBNS wants to flush the
* name from the local name table, or from the local
* cache.
*/
IF name exists in the local name table THEN
BEGIN
delete name from local name table;
inform user that name has been deleted;
END
ELSE
IF name has been cached locally THEN
BEGIN
remove entry from cache:
END
END /* case */
END /* procedure */
5.1.2.6. P-NODE TIMER INITIATED PROCESSING
Processing initiated by timer expiration.
PROCEDURE timer_expired()
/*
* Processing initiated by the expiration of a timer on a P node
*/
BEGIN
/*
* Send a NAME REFRESH REQUEST for each name which the
* TTL which has expired.
*/
REPEAT
build NAME REFRESH REQUEST packet;
REPEAT
send packet to NBNS;
IF receive a WACK RESPONSE THEN
pause(time from TTL field of response);
NetBIOS Working Group [Page 49]
RFC 1002 March 1987
ELSE
pause(UCAST_REQ_RETRY_TIMEOUT);
UNTIL response packet is received or
retransmit count has been exceeded
CASE packet type OF
POSITIVE NAME REGISTRATION RESPONSE:
/* successfully refreshed */
reset TTL timer for this name;
NEGATIVE NAME REGISTRATION RESPONSE:
/*
* refused, can't keep name
* assume in conflict
*/
mark name as in conflict;
END /* case */
UNTIL request sent for all names for which TTL
has expired
END /* procedure */
5.1.3. M ノードの動作
M nodes behavior is similar to that of P nodes with the addition
of some B node-like broadcast actions. M node name service
proceeds in two steps:
1.Use broadcast UDP based name service. Depending on the
operation, goto step 2.
2.Use directed UDP name service.
The following code for M nodes is exactly the same as for a P
node, with the exception that broadcast operations are done
before P type operation is attempted.
5.1.3.1. M-NODE ADD NAME
PROCEDURE add_name(newname)
/*
* Host initiated processing for a M node
*/
BEGIN
/*
* check if name exists on the
* broadcast area
*/
NetBIOS Working Group [Page 50]
RFC 1002 March 1987
REPEAT
/* build packet */
....
broadcast NAME REGISTRATION REQUEST packet;
pause(BCAST_REQ_RETRY_TIMEOUT);
UNTIL response packet is received or
retransmit count has been exceeded
IF valid response received THEN
BEGIN
/* cannot claim name */
return failure;
END
/*
* No objections received within the
* broadcast area.
* Send request to name server.
*/
REPEAT
/*
* build packet
*/
ONT = M;
...
unicast NAME REGISTRATION REQUEST packet;
/*
* remote NBNS will send response packet
*/
IF receive a WACK RESPONSE THEN
pause(time from TTL field of response);
ELSE
pause(UCAST_REQ_RETRY_TIMEOUT);
UNTIL response packet is received or
retransmit count has been exceeded
IF no response packet was received THEN
BEGIN /* no response */
/*
* NBNS is down. Cannot claim name.
*/
NetBIOS Working Group [Page 51]
RFC 1002 March 1987
return failure; /* name cannot be claimed */
END /* no response */
ELSE
BEGIN /* response */
IF NOT response tid = request tid THEN
BEGIN
ignore response packet;
END
ELSE
CASE packet type OF
POSITIVE NAME REGISTRATION RESPONSE:
/*
* name can be added
*/
adjust refresh timeout value, TTL;
return success; /* name can be added */
NEGATIVE NAME REGISTRATION RESPONSE:
return failure; /* name cannot be added */
END-NODE CHALLENGE REGISTRATION REQUEST:
BEGIN /* end node challenge */
/*
* The response packet has in it the
* address of the presumed owner of the
* name. Challenge that owner.
* If owner either does not
* respond or indicates that he no longer
* owns the name, claim the name.
* Otherwise, the name cannot be claimed.
*
*/
REPEAT
/*
* build packet
*/
...
/*
* send packet to address contained in the
* response packet
*/
unicast NAME QUERY REQUEST packet;
/*
* remote node may send response packet
NetBIOS Working Group [Page 52]
RFC 1002 March 1987
*/
pause(UCAST_REQ_RETRY_TIMEOUT);
UNTIL response packet is received or
retransmit count has been exceeded
IF no response packet is received THEN
BEGIN /* no response */
/*
* name can be claimed
*/
REPEAT
/*
* build packet
*/
...
unicast NAME UPDATE REQUEST to NBNS;
/*
* NBNS node will send response packet
*/
IF receive a WACK RESPONSE THEN
pause(time from TTL field of response);
ELSE
pause(UCAST_REQ_RETRY_TIMEOUT);
UNTIL response packet is received or
retransmit count has been exceeded
IF no response packet received THEN
BEGIN /* no response */
/*
* name could not be claimed
*/
return failure;
END /* no response */
ELSE
CASE packet type OF
POSITIVE NAME REGISTRATION RESPONSE:
/*
* add name
*/
return success;
NEGATIVE NAME REGISTRATION RESPONSE:
NetBIOS Working Group [Page 53]
RFC 1002 March 1987
/*
* you lose ...
*/
return failure;
END /* case */
END /* no response */
ELSE
IF NOT response tid = request tid THEN
BEGIN
ignore response packet;
END
/*
* received a response to the "challenge"
* packet
*/
CASE packet type OF
POSITIVE NAME QUERY:
/*
* remote node still has name.
*/
return failure;
NEGATIVE NAME QUERY:
/*
* remote node no longer has name
*/
return success;
END /* case */
END /* end node challenge */
END /* case */
END /* response */
END /* procedure */
5.1.3.2. M-NODE ADD GROUP NAME
PROCEDURE add_group_name(newname)
/*
* Host initiated processing for a P node
*/
BEGIN
/*
* same as for a unique name, except that the
* request packet must indicate that a
NetBIOS Working Group [Page 54]
RFC 1002 March 1987
* group name claim is being made.
*/
...
G = GROUP;
...
/*
* send packet
*/
...
END
5.1.3.3. M-NODE FIND NAME
PROCEDURE find_name(name)
/*
* Host initiated processing for a M node
*/
BEGIN
/*
* check if any node on the broadcast
* area has the name
*/
REPEAT
/* build packet */
...
broadcast NAME QUERY REQUEST packet;
pause(BCAST_REQ_RETRY_TIMEOUT);
UNTIL response packet received OR
max transmit threshold exceeded
IF valid response received THEN
BEGIN
save response as authoritative response;
start_timer(CONFLICT_TIMER);
return success;
END
/*
* no valid response on the b'cast segment.
* Try the name server.
*/
REPEAT
NetBIOS Working Group [Page 55]
RFC 1002 March 1987
/*
* build packet
*/
ONT = M;
G = DONT CARE;
unicast NAME QUERY REQUEST packet to NBNS;
/*
* a NBNS node might send response packet
*/
IF receive a WACK RESPONSE THEN
pause(time from TTL field of response);
ELSE
pause(UCAST_REQ_RETRY_TIMEOUT);
UNTIL response packet received OR
max transmit threshold exceeded
IF no response packet received THEN
return failure;
ELSE
IF NOT response tid = request tid THEN
ignore packet;
ELSE
CASE packet type OF
POSITIVE NAME QUERY RESPONSE:
return success;
REDIRECT NAME QUERY RESPONSE:
/*
* NBNS node wants this end node
* to use some other NBNS node
* to resolve the query.
*/
repeat query with NBNS address
in the response packet;
NEGATIVE NAME QUERY RESPONSE:
return failure;
END /* case */
END /* procedure */
5.1.3.4. M-NODE DELETE NAME
PROCEDURE delete_name (name)
/*
NetBIOS Working Group [Page 56]
RFC 1002 March 1987
* Host initiated processing for a P node
*/
BEGIN
/*
* First, delete name on NBNS
*/
REPEAT
/*
* build packet
*/
...
/*
* send request
*/
unicast NAME RELEASE REQUEST packet to NBNS;
IF receive a WACK RESPONSE THEN
pause(time from TTL field of response);
ELSE
pause(UCAST_REQ_RETRY_TIMEOUT);
UNTIL retransmit count has been exceeded
or response been received
IF response has been received THEN
CASE packet type OF
POSITIVE NAME RELEASE RESPONSE:
/*
* Deletion of name on b'cast segment is deferred
* until after NBNS has deleted the name
*/
REPEAT
/* build packet */
...
broadcast NAME RELEASE REQUEST;
pause(BCAST_REQ_RETRY_TIMEOUT);
UNTIL rexmt threshold exceeded
return success;
NEGATIVE NAME RELEASE RESPONSE:
/*
* NBNS does want node to delete this
* name
*/
NetBIOS Working Group [Page 57]
RFC 1002 March 1987
return failure;
END /* case */
END /* procedure */
5.1.3.5. M-NODE INCOMING PACKET PROCESSING
Processing initiated by reception of packets at a M node
PROCEDURE process_incoming_packet(packet)
/*
* Processing initiated by incoming packets at a M node
*/
BEGIN
CASE packet type of
NAME CONFLICT DEMAND:
IF name exists in local name table THEN
mark name as in conflict;
return;
NAME QUERY REQUEST:
IF name exists in local name table THEN
BEGIN /* name exists */
/*
* build packet
*/
...
/*
* send response to the IP address and port
* number from which the request was received.
*/
send POSITIVE NAME QUERY RESPONSE ;
return;
END /* exists */
ELSE
BEGIN /* does not exist */
/*
* send response to the requestor
*/
IF request NOT broadcast THEN
/*
* Don't send negative responses to
* queries sent by B nodes
*/
NetBIOS Working Group [Page 58]
RFC 1002 March 1987
send NEGATIVE NAME QUERY RESPONSE ;
return;
END /* does not exist */
NODE STATUS REQUEST:
BEGIN
/*
* Name of "*" may be used for force node to
* divulge status for administrative purposes
*/
IF name in local name table OR name = "*" THEN
/*
* Build response packet and
* send to requestor node
* Send only those names that are
* in the same scope as the scope
* in the request packet.
*/
send NODE STATUS RESPONSE;
END
NAME RELEASE REQUEST:
/*
* This will be received if the NBNS wants to flush the
* name from the local name table, or from the local
* cache.
*/
IF name exists in the local name table THEN
BEGIN
delete name from local name table;
inform user that name has been deleted;
END
ELSE
IF name has been cached locally THEN
BEGIN
remove entry from cache:
END
NAME REGISTRATION REQUEST (UNIQUE):
IF name exists in local name table THEN
send NEGATIVE NAME REGISTRATION RESPONSE ;
NAME REGISTRATION REQUEST (GROUP):
IF name exists in local name table THEN
BEGIN
IF local entry is a unique name THEN
send NEGATIVE NAME REGISTRATION RESPONSE ;
END
END /* case */
END /* procedure */
NetBIOS Working Group [Page 59]
RFC 1002 March 1987
5.1.3.6. M-NODE TIMER INITIATED PROCESSING
Processing initiated by timer expiration:
PROCEDURE timer_expired()
/*
* Processing initiated by the expiration of a timer on a M node
*/
BEGIN
/*
* Send a NAME REFRESH REQUEST for each name which the
* TTL which has expired.
*/
REPEAT
build NAME REFRESH REQUEST packet;
REPEAT
send packet to NBNS;
IF receive a WACK RESPONSE THEN
pause(time from TTL field of response);
ELSE
pause(UCAST_REQ_RETRY_TIMEOUT);
UNTIL response packet is received or
retransmit count has been exceeded
CASE packet type OF
POSITIVE NAME REGISTRATION RESPONSE:
/* successfully refreshed */
reset TTL timer for this name;
NEGATIVE NAME REGISTRATION RESPONSE:
/*
* refused, can't keep name
* assume in conflict
*/
mark name as in conflict;
END /* case */
UNTIL request sent for all names for which TTL
has expired
END /* procedure */
5.1.4. NBNS の動作
A NBNS node will receive directed packets from P and M nodes.
Reply packets are always sent as directed packets to the source
IP address and UDP port number. Received broadcast packets must
be ignored.
NetBIOS Working Group [Page 60]
RFC 1002 March 1987
5.1.4.1. NBNS INCOMING PACKET PROCESSING
PROCEDURE process_incoming_packet(packet)
/*
* Incoming packet processing on a NS node
*/
BEGIN
IF packet was sent as a broadcast THEN
BEGIN
discard packet;
return;
END
CASE packet type of
NAME REGISTRATION REQUEST (UNIQUE):
IF unique name exists in data base THEN
BEGIN /* unique name exists */
/*
* NBNS node may be a "passive"
* server in that it expects the
* end node to do the challenge
* server. Such a NBNS node is
* called a "non-secure" server.
* A "secure" server will do the
* challenging before it sends
* back a response packet.
*/
IF non-secure THEN
BEGIN
/*
* build response packet
*/
...
/*
* let end node do the challenge
*/
send END-NODE CHALLENGE NAME REGISTRATION
RESPONSE;
return;
END
ELSE
/*
* secure server - do the name
* challenge operation
*/
NetBIOS Working Group [Page 61]
RFC 1002 March 1987
REPEAT
send NAME QUERY REQUEST;
pause(UCAST_REQ_RETRY_TIMEOUT);
UNTIL response has been received or
retransmit count has been exceeded
IF no response was received THEN
BEGIN
/* node down */
update data base - remove entry;
update data base - add new entry;
send POSITIVE NAME REGISTRATION RESPONSE;
return;
END
ELSE
BEGIN /* challenged node replied */
/*
* challenged node replied with
* a response packet
*/
CASE packet type
POSITIVE NAME QUERY RESPONSE:
/*
* name still owned by the
* challenged node
*
* build packet and send response
*/
...
/*
* Note: The NBNS will need to
* keep track (based on transaction id) of
* the IP address and port number
* of the original requestor.
*/
send NEGATIVE NAME REGISTRATION RESPONSE;
return;
NEGATIVE NAME QUERY RESPONSE:
update data base - remove entry;
update data base - add new entry;
/*
* build response packet and send
NetBIOS Working Group [Page 62]
RFC 1002 March 1987
* response
*/
send POSITIVE NAME REGISTRATION RESPONSE;
return;
END /* case */
END /* challenged node replied */
END /* unique name exists in data base */
ELSE
IF group name exists in data base THEN
BEGIN /* group names exists */
/*
* Members of a group name are NOT
* challenged.
* Make the assumption that
* at least some of the group members
* are still alive.
* Refresh mechanism will
* allow the NBNS to detect when all
* members of a group no longer use that
* name
*/
send NEGATIVE NAME REGISTRATION RESPONSE;
END /* group name exists */
ELSE
BEGIN /* name does not exist */
/*
* Name does not exist in data base
*
* This code applies to both non-secure
* and secure server.
*/
update data base - add new entry;
send POSITIVE NAME REGISTRATION RESPONSE;
return;
END
NAME QUERY REQUEST:
IF name exists in data base THEN
BEGIN
/*
* build response packet and send to
* requestor
*/
...
send POSITIVE NAME QUERY RESPONSE;
return;
NetBIOS Working Group [Page 63]
RFC 1002 March 1987
ELSE
BEGIN
/*
* build response packet and send to
* requestor
*/
...
send NEGATIVE NAME QUERY RESPONSE;
return;
END
NAME REGISTRATION REQUEST (GROUP):
IF name exists in data base THEN
BEGIN
IF local entry is a unique name THEN
BEGIN /* local is unique */
IF non-secure THEN
BEGIN
send END-NODE CHALLENGE NAME
REGISTRATION RESPONSE;
return;
END
REPEAT
send NAME QUERY REQUEST;
pause(UCAST_REQ_RETRY_TIMEOUT);
UNTIL response received or
retransmit count exceeded
IF no response received or
NEGATIVE NAME QUERY RESPONSE
received THEN
BEGIN
update data base - remove entry;
update data base - add new entry;
send POSITIVE NAME REGISTRATION RESPONSE;
return;
END
ELSE
BEGIN
/*
* name still being held
* by challenged node
*/
send NEGATIVE NAME REGISTRATION RESPONSE;
END
END /* local is unique */
ELSE
BEGIN /* local is group */
NetBIOS Working Group [Page 64]
RFC 1002 March 1987
/*
* existing entry is a group name
*/
update data base - remove entry;
update data base - add new entry;
send POSITIVE NAME REGISTRATION RESPONSE;
return;
END /* local is group */
END /* names exists */
ELSE
BEGIN /* does not exist */
/* name does not exist in data base */
update data base - add new entry;
send POSITIVE NAME REGISTRATION RESPONSE;
return;
END /* does not exist */
NAME RELEASE REQUEST:
/*
* secure server may choose to disallow
* a node from deleting a name
*/
update data base - remove entry;
send POSITIVE NAME RELEASE RESPONSE;
return;
NAME UPDATE REQUEST:
/*
* End-node completed a successful challenge,
* no update database
*/
IF secure server THEN
send NEGATIVE NAME REGISTRATION RESPONSE;
ELSE
BEGIN /* new entry */
IF entry already exists THEN
update data base - remove entry;
update data base - add new entry;
send POSITIVE NAME REGISTRATION RESPONSE;
start_timer(TTL);
END
NAME REFRESH REQUEST:
check for consistency;
NetBIOS Working Group [Page 65]
RFC 1002 March 1987
IF node not allowed to have name THEN
BEGIN
/*
* tell end node that it can't have name
*/
send NEGATIVE NAME REGISTRATION RESPONSE;
END
ELSE
BEGIN
/*
* send confirmation response to the
* end node.
*/
send POSITIVE NAME REGISTRATION;
start_timer(TTL);
END
return;
END /* case */
END /* procedure */
5.1.4.2. NBNS TIMER INITIATED PROCESSING
A NS node uses timers to flush out entries from the data base.
Each entry in the data base is removed when its timer expires.
This time value is a multiple of the refresh TTL established when
the name was registered.
PROCEDURE timer_expired()
/*
* processing initiated by expiration of TTL for a given name
*/
BEGIN
/*
* NBNS can (optionally) ensure
* that the node is actually down
* by sending a NODE STATUS REQUEST.
* If such a request is sent, and
* no response is received, it can
* be assumed that the node is down.
*/
remove entry from data base;
END
NetBIOS Working Group [Page 66]
RFC 1002 March 1987
5.2. セッションサービスプロトコル
以下に示すのは、NetBIOS ユーザが設定することが望ましい変数である。
これらの変数のデフォルト値は「定義済の定数と変数」にて詳細な仕様が
記載されている:
- SSN_RETRY_COUNT - 単一の NetBIOS 呼出のリクエストにおける TCP 接
続の最大試行回数
- SSN_CLOSE_TIMEOUT is the time period to wait when closing the
NetBIOS session before killing the TCP connection if session
sends are outstanding.
The following are Defined Constants for the NetBIOS Session
Service. (See "Defined Constants and Variables" in the Detailed
Specification for the value of these constants):
- SSN_SRVC_TCP_PORT - is the globally well-known TCP port
allocated for the NetBIOS Session Service. The service accepts
TCP connections on this port to establish NetBIOS Sessions.
The TCP connection established to this port by the caller is
initially used for the exchange of NetBIOS control information.
The actual NetBIOS data connection may also pass through this
port or, through the retargetting facility, through another
port.
5.2.1. セッション確立プロトコル
5.2.1.1. USER REQUEST PROCESSING
PROCEDURE listen(listening name, caller name)
/*
* User initiated processing for B, P and M nodes
*
* This procedure assumes that an incoming session will be
* retargetted here by a session server.
*/
BEGIN
Do TCP listen; /* Returns TCP port used */
Register listen with Session Service, give names and
TCP port;
Wait for TCP connection to open; /* Incoming call */
Read SESSION REQUEST packet from connection
Process session request (see section on
processing initiated by the reception of session
service packets);
NetBIOS Working Group [Page 67]
RFC 1002 March 1987
Inform Session Service that NetBIOS listen is complete;
IF session established THEN
return success and session information to user;
ELSE
return failure;
END /* procedure */
PROCEDURE call(calling name, called name)
/*
* user initiated processing for B, P and M nodes
*/
/*
* This algorithm assumes that the called name is a unique name.
* If the called name is a group name, the call() procedure
* needs to cycle through the members of the group
* until either (retry_count == SSN_RETRY_COUNT) or
* the list has been exhausted.
*/
BEGIN
retry_count = 0;
retarget = FALSE; /* TRUE: caller is being retargetted */
name_query = TRUE; /* TRUE: caller must begin again with */
/* name query. */
REPEAT
IF name_query THEN
BEGIN
do name discovery, returns IP address;
TCP port = SSN_SRVC_TCP_PORT;
IF name discovery fails THEN
return failure;
ELSE
name_query = FALSE;
END
/*
* now have IP address and TCP port of
* remote party.
*/
establish TCP connection with remote party, use an
ephemeral port as source TCP port;
IF connection refused THEN
BEGIN
IF retarget THEN
BEGIN
/* retry */
retarget = FALSE;
NetBIOS Working Group [Page 68]
RFC 1002 March 1987
use original IP address and TCP port;
goto LOOP;
END
/* retry for just missed TCP listen */
pause(SESSION_RETRY_TIMER);
establish TCP connection, again use ephemeral
port as source TCP port;
IF connection refused OR
connection timed out THEN
return failure;
END
ELSE
IF connection timed out THEN
BEGIN
IF retarget THEN
BEGIN
/* retry */
retarget = FALSE;
use original IP address and TCP port;
goto LOOP;
END
ELSE
BEGIN
/*
* incorrect name discovery was done,
* try again
*/
inform name discovery process of
possible error;
name_query = TRUE;
goto LOOP;
END
END
/*
* TCP connection has been established
*/
wait for session response packet;
CASE packet type OF
POSITIVE SESSION RESPONSE:
return success and session established
information;
NEGATIVE SESSION RESPONSE:
BEGIN
NetBIOS Working Group [Page 69]
RFC 1002 March 1987
CASE error OF
NOT LISTENING ON CALLED NAME:
NOT LISTENING FOR CALLING NAME:
BEGIN
kill TCP connection;
return failure;
END
CALLED NAME NOT PRESENT:
BEGIN
/*
* called name does not exist on
* remote node
*/
inform name discovery procedure
of possible error;
IF this is a P or M node THEN
BEGIN
/*
* Inform NetBIOS Name Server
* it has returned incorrect
* information.
*/
send NAME RELEASE REQUEST for called
name and IP address to
NetBIOS Name Server;
END
/* retry from beginning */
retarget = FALSE;
name_query = TRUE;
goto LOOP;
END /* called name not present */
END /* case */
END /* negative response */
RETARGET SESSION RESPONSE:
BEGIN
close TCP connection;
extract IP address and TCP port from
response;
retarget = TRUE;
END /* retarget response */
END /* case */
LOOP: retry_count = retry_count + 1;
UNTIL (retry_count > SSN_RETRY_COUNT);
return failure;
END /* procedure */
NetBIOS Working Group [Page 70]
RFC 1002 March 1987
5.2.1.2. RECEIVED PACKET PROCESSING
These are packets received on a TCP connection before a session
has been established. The listen routines attached to a NetBIOS
user process need not implement the RETARGET response section.
The user process version, separate from a shared Session Service,
need only accept (POSITIVE SESSION RESPONSE) or reject (NEGATIVE
SESSION RESPONSE) a session request.
PROCEDURE session_packet(packet)
/*
* processing initiated by receipt of a session service
* packet for a session in the session establishment phase.
* Assumes the TCP connection has been accepted.
*/
BEGIN
CASE packet type
SESSION REQUEST:
BEGIN
IF called name does not exist on node THEN
BEGIN
send NEGATIVE SESSION RESPONSE with CALLED
NAME NOT PRESENT error code;
close TCP connection;
END
Search for a listen with CALLING NAME for CALLED
NAME;
IF matching listen is found THEN
BEGIN
IF port of listener process is port TCP
connection is on THEN
BEGIN
send POSITIVE SESSION RESPONSE;
Hand off connection to client process
and/or inform user session is
established;
END
ELSE
BEGIN
send RETARGET SESSION RESPONSE with
listener's IP address and
TCP port;
close TCP connection;
END
END
ELSE
BEGIN
/* no matching listen pending */
NetBIOS Working Group [Page 71]
RFC 1002 March 1987
send NEGATIVE SESSION RESPONSE with either
NOT LISTENING ON CALLED NAME or NOT
LISTENING FOR CALLING NAME error
code;
close TCP connection;
END
END /* session request */
END /* case */
END /* procedure */
5.2.2. SESSION DATA TRANSFER PROTOCOLS
5.2.2.1. USER REQUEST PROCESSING
PROCEDURE send_message(user_message)
BEGIN
build SESSION MESSAGE header;
send SESSION MESSAGE header;
send user_message;
reset and restart keep-alive timer;
IF send fails THEN
BEGIN
/*
* TCP connection has failed */
*/
close NetBIOS session;
inform user that session is lost;
return failure;
END
ELSE
return success;
END
5.2.2.2. RECEIVED PACKET PROCESSING
These are packets received after a session has been established.
PROCEDURE session_packet(packet)
/*
* processing initiated by receipt of a session service
* packet for a session in the data transfer phase.
*/
BEGIN
CASE packet type OF
SESSION MESSAGE:
BEGIN
process message header;
read in user data;
reset and restart keep-alive timer;
deliver data to user;
NetBIOS Working Group [Page 72]
RFC 1002 March 1987
END /* session message */
SESSION KEEP ALIVE:
discard packet;
END /* case */
END /* procedure */
5.2.2.3. PROCESSING INITIATED BY TIMER
PROCEDURE session_ka_timer()
/*
* processing initiated when session keep alive timer expires
*/
BEGIN
send SESSION KEEP ALIVE, if configured;
IF send fails THEN
BEGIN
/* remote node, or path to it, is down */
abort TCP connection;
close NetBIOS session;
inform user that session is lost;
return;
END
END /* procedure */
5.2.3. SESSION TERMINATION PROTOCOLS
5.2.3.1. USER REQUEST PROCESSING
PROCEDURE close_session()
/* initiated by a user request to close a session */
BEGIN
close gracefully the TCP connection;
WAIT for the connection to close or SSN_CLOSE_TIMEOUT
to expire;
IF time out expired THEN
abort TCP connection;
END /* procedure */
5.2.3.2. RECEPTION INDICATION PROCESSING
PROCEDURE close_indication()
/*
* initiated by a TCP indication of a close request from
* the remote connection partner.
NetBIOS Working Group [Page 73]
RFC 1002 March 1987
*/
BEGIN
close gracefully TCP connection;
close NetBIOS session;
inform user session closed by remote partner;
END /* procedure */
5.3. NetBIOS データグラムサービスプロトコル
以下は、NetBIOS ユーザが設定変更可能なグローバル変数である:
- SCOPE_ID: the non-leaf section of the domain name preceded by a
'.' which represents the domain of the NetBIOS scope for the
NetBIOS name. The following protocol description only supports
single scope operation.
- MAX_DATAGRAM_LENGTH: the maximum length of an IP datagram. The
minimal maximum length defined in for IP is 576 bytes. This
value is used when determining whether to fragment a NetBIOS
datagram. Implementations are expected to be capable of
receiving unfragmented NetBIOS datagrams up to their maximum
size.
- BROADCAST_ADDRESS: B ノードがグループ名の宛先に対するデータグラム
の送信やブロードキャストのデータグラム送信に用いる IP アドレス。
デフォルトは IP ネットワークの IP ブロードキャストアドレス
以下は、NetBIOS データグラムサービスの定義済定数である:
- DGM_SRVC_UDP_PORT: the globally well-known UDP port allocated
where the NetBIOS Datagram Service receives UDP packets. See
section 6, "Defined Constants", for its value.
5.3.1. B ノードによる NetBIOS データグラムの送信
PROCEDURE send_datagram(data, source, destination, broadcast)
/*
* user initiated processing on B node
*/
BEGIN
group = FALSE;
do name discovery on destination name, returns name type and
IP address;
NetBIOS Working Group [Page 74]
RFC 1002 March 1987
IF name type is group name THEN
BEGIN
group = TRUE;
END
/*
* build datagram service UDP packet;
*/
convert source and destination NetBIOS names into
half-ASCII, biased encoded name;
SOURCE_NAME = cat(source, SCOPE_ID);
SOURCE_IP = this nodes IP address;
SOURCE_PORT = DGM_SRVC_UDP_PORT;
IF NetBIOS broadcast THEN
BEGIN
DESTINATION_NAME = cat("*", SCOPE_ID)
END
ELSE
BEGIN
DESTINATION_NAME = cat(destination, SCOPE_ID)
END
MSG_TYPE = select_one_from_set
{BROADCAST, DIRECT_UNIQUE, DIRECT_GROUP}
DGM_ID = next transaction id for Datagrams;
DGM_LENGTH = length of data + length of second level encoded
source and destination names;
IF (length of the NetBIOS Datagram, including UDP and
IP headers, > MAX_DATAGRAM_LENGTH) THEN
BEGIN
/*
* fragment NetBIOS datagram into 2 UDP packets
*/
Put names into 1st UDP packet and any data that fits
after names;
Set MORE and FIRST bits in 1st UDP packet's FLAGS;
OFFSET in 1st UDP = 0;
Replicate NetBIOS Datagram header from 1st UDP packet
into 2nd UDP packet;
Put rest of data in 2nd UDP packet;
Clear MORE and FIRST bits in 2nd UDP packet's FLAGS;
OFFSET in 2nd UDP = DGM_LENGTH - number of name and
data bytes in 1st UDP;
END
BEGIN
/*
* Only need one UDP packet
*/
NetBIOS Working Group [Page 75]
RFC 1002 March 1987
USER_DATA = data;
Clear MORE bit and set FIRST bit in FLAGS;
OFFSET = 0;
END
IF (group == TRUE) OR (NetBIOS broadcast) THEN
BEGIN
send UDP packet(s) to BROADCAST_ADDRESS;
END
ELSE
BEGIN
send UDP packet(s) to IP address returned by name
discovery;
END
END /* procedure */
5.3.2. P AND M NODE TRANSMISSION OF NetBIOS DATAGRAMS
PROCEDURE send_datagram(data, source, destination, broadcast)
/*
* User initiated processing on P and M node.
*
* This processing is the same as for B nodes except for
* sending broadcast and multicast NetBIOS datagrams.
*/
BEGIN
group = FALSE;
do name discovery on destination name, returns name type
and IP address;
IF name type is group name THEN
BEGIN
group = TRUE;
END
/*
* build datagram service UDP packet;
*/
convert source and destination NetBIOS names into
half-ASCII, biased encoded name;
SOURCE_NAME = cat(source, SCOPE_ID);
SOURCE_IP = this nodes IP address;
SOURCE_PORT = DGM_SRVC_UDP_PORT;
IF NetBIOS broadcast THEN
BEGIN
DESTINATION_NAME = cat("*", SCOPE_ID)
END
ELSE
NetBIOS Working Group [Page 76]
RFC 1002 March 1987
BEGIN
DESTINATION_NAME = cat(destination, SCOPE_ID)
END
MSG_TYPE = select_one_from_set
{BROADCAST, DIRECT_UNIQUE, DIRECT_GROUP}
DGM_ID = next transaction id for Datagrams;
DGM_LENGTH = length of data + length of second level encoded
source and destination names;
IF (length of the NetBIOS Datagram, including UDP and
IP headers, > MAX_DATAGRAM_LENGTH) THEN
BEGIN
/*
* fragment NetBIOS datagram into 2 UDP packets
*/
Put names into 1st UDP packet and any data that fits
after names;
Set MORE and FIRST bits in 1st UDP packet's FLAGS;
OFFSET in 1st UDP = 0;
Replicate NetBIOS Datagram header from 1st UDP packet
into 2nd UDP packet;
Put rest of data in 2nd UDP packet;
Clear MORE and FIRST bits in 2nd UDP packet's FLAGS;
OFFSET in 2nd UDP = DGM_LENGTH - number of name and
data bytes in 1st UDP;
END
BEGIN
/*
* Only need one UDP packet
*/
USER_DATA = data;
Clear MORE bit and set FIRST bit in FLAGS;
OFFSET = 0;
END
IF (group == TRUE) OR (NetBIOS broadcast) THEN
BEGIN
/*
* Sending of following query is optional.
* Node may send datagram to NBDD immediately
* but NBDD may discard the datagram.
*/
send DATAGRAM QUERY REQUEST to NBDD;
IF response is POSITIVE QUERY RESPONSE THEN
send UDP packet(s) to NBDD Server IP address;
ELSE
BEGIN
get list of destination nodes from NBNS;
NetBIOS Working Group [Page 77]
RFC 1002 March 1987
FOR EACH node in list
BEGIN
send UDP packet(s) to this node's
IP address;
END
END
END
ELSE
BEGIN
send UDP packet(s) to IP address returned by name
discovery;
END /* procedure */
5.3.3. RECEPTION OF NetBIOS DATAGRAMS BY ALL NODES
The following algorithm discards out of order NetBIOS Datagram
fragments. An implementation which reassembles out of order
NetBIOS Datagram fragments conforms to this specification. The
fragment discard timer is initialized to the value FRAGMENT_TO.
This value should be user configurable. The default value is
given in Section 6, "Defined Constants and Variables".
PROCEDURE datagram_packet(packet)
/*
* processing initiated by datagram packet reception
* on B, P and M nodes
*/
BEGIN
/*
* if this node is a P node, ignore
* broadcast packets.
*/
IF this is a P node AND incoming packet is
a broadcast packet THEN
BEGIN
discard packet;
END
CASE packet type OF
DATAGRAM SERVICE:
BEGIN
IF FIRST bit in FLAGS is set THEN
BEGIN
IF MORE bit in FLAGS is set THEN
BEGIN
Save 1st UDP packet of the Datagram;
Set this Datagram's fragment discard
timer to FRAGMENT_TO;
NetBIOS Working Group [Page 78]
RFC 1002 March 1987
return;
END
ELSE
Datagram is composed of a single
UDP packet;
END
ELSE
BEGIN
/* Have the second fragment of a Datagram */
Search for 1st fragment by source IP address
and DGM_ID;
IF found 1st fragment THEN
Process both UDP packets;
ELSE
BEGIN
discard 2nd fragment UDP packet;
return;
END
END
IF DESTINATION_NAME is '*' THEN
BEGIN
/* NetBIOS broadcast */
deliver USER_DATA from UDP packet(s) to all
outstanding receive broadcast
datagram requests;
return;
END
ELSE
BEGIN /* non-broadcast */
/* Datagram for Unique or Group Name */
IF DESTINATION_NAME is not present in the
local name table THEN
BEGIN
/* destination not present */
build DATAGRAM ERROR packet, clear
FIRST and MORE bit, put in
this nodes IP and PORT, set
ERROR_CODE;
send DATAGRAM ERROR packet to
source IP address and port
of UDP;
discard UDP packet(s);
return;
END
ELSE
BEGIN /* good */
/*
NetBIOS Working Group [Page 79]
RFC 1002 March 1987
* Replicate received NetBIOS datagram for
* each recipient
*/
FOR EACH pending NetBIOS user's receive
datagram operation
BEGIN
IF source name of operation
matches destination name
of packet THEN
BEGIN
deliver USER_DATA from UDP
packet(s);
END
END /* for each */
return;
END /* good */
END /* non-broadcast */
END /* datagram service */
DATAGRAM ERROR:
BEGIN
/*
* name service returned incorrect information
*/
inform local name service that incorrect
information was provided;
IF this is a P or M node THEN
BEGIN
/*
* tell NetBIOS Name Server that it may
* have given incorrect information
*/
send NAME RELEASE REQUEST with name
and incorrect IP address to NetBIOS
Name Server;
END
END /* datagram error */
END /* case */
END
5.3.4. PROTOCOLS FOR THE NBDD
The key to NetBIOS Datagram forwarding service is the packet
delivered to the destination end node must have the same NetBIOS
header as if the source end node sent the packet directly to the
destination end node. Consequently, the NBDD does not reassemble
NetBIOS Datagrams. It forwards the UDP packet as is.
NetBIOS Working Group [Page 80]
RFC 1002 March 1987
PROCEDURE datagram_packet(packet)
/*
* processing initiated by a incoming datagram service
* packet on a NBDD node.
*/
BEGIN
CASE packet type OF
DATAGRAM SERVICE:
BEGIN
IF packet was sent as a directed
NetBIOS datagram THEN
BEGIN
/*
* provide group forwarding service
*
* Forward datagram to each member of the
* group. Can forward via:
* 1) get list of group members and send
* the DATAGRAM SERVICE packet unicast
* to each
* 2) use Group Multicast, if available
* 3) combination of 1) and 2)
*/
...
END
ELSE
BEGIN
/*
* provide broadcast forwarding service
*
* Forward datagram to every node in the
* NetBIOS scope. Can forward via:
* 1) get list of group members and send
* the DATAGRAM SERVICE packet unicast
* to each
* 2) use Group Multicast, if available
* 3) combination of 1) and 2)
*/
...
END
END /* datagram service */
DATAGRAM ERROR:
NetBIOS Working Group [Page 81]
RFC 1002 March 1987
BEGIN
/*
* Should never receive these because Datagrams
* forwarded have source end node IP address and
* port in NetBIOS header.
*/
send DELETE NAME REQUEST with incorrect name and
IP address to NetBIOS Name Server;
END /* datagram error */
DATAGRAM QUERY REQUEST:
BEGIN
IF can send packet to DESTINATION_NAME THEN
BEGIN
/*
* NBDD is able to relay Datagrams for
* this name
*/
send POSITIVE DATAGRAM QUERY RESPONSE to
REQUEST source IP address and UDP port
with request's DGM_ID;
END
ELSE
BEGIN
/*
* NBDD is NOT able to relay Datagrams for
* this name
*/
send NEGATIVE DATAGRAM QUERY RESPONSE to
REQUEST source IP address and UDP port
with request's DGM_ID;
END
END /* datagram query request */
END /* case */
END /* procedure */
NetBIOS Working Group [Page 82]
RFC 1002 March 1987
6. 定義済の定数と変数
共通:
SCOPE_ID NetBIOS スコープ名
This is expressed as a character
string meeting the requirements of
the domain name system and without
a leading or trailing "dot".
An implementation may elect to make
this a single global value for the
node or allow it to be specified
with each separate NetBIOS name
(thus permitting cross-scope
references.)
BROADCAST_ADDRESS An IP address composed of the
nodes's network and subnetwork
numbers with all remaining bits set
to one.
I.e. "Specific subnet" broadcast
addressing according to section 2.3
of RFC 950.
BCAST_REQ_RETRY_TIMEOUT 250 milliseconds.
An adaptive timer may be used.
BCAST_REQ_RETRY_COUNT 3
UCAST_REQ_RETRY_TIMEOUT 5 秒
An adaptive timer may be used.
UCAST_REQ_RETRY_COUNT 3
MAX_DATAGRAM_LENGTH 576 バイト (デフォルト)
ネームサービス:
REFRESH_TIMER 名前毎に NBNS とネゴシエーションされる
CONFLICT_TIMER 1 秒
実装により、より長い値を設定しても良
い
NAME_SERVICE_TCP_PORT 137 (10進数)
NetBIOS Working Group [Page 83]
RFC 1002 March 1987
NAME_SERVICE_UDP_PORT 137 (10進数)
INFINITE_TTL 0
SESSION SERVICE:
SSN_SRVC_TCP_PORT 139 (10進数)
SSN_RETRY_COUNT 4 (デフォルト)
ユーザによる設定変更が可能
SSN_CLOSE_TIMEOUT 30 秒 (デフォルト)
ユーザによる設定変更が可能
SSN_KEEP_ALIVE_TIMEOUT 60 秒、この値を推奨するが、より大きい
値に設定してもよい。
(セッションキープアライブは設定された
場合のみ用いられる)
データグラムサービス:
DGM_SRVC_UDP_PORT 138 (10進数)
FRAGMENT_TO 2 秒 (デフォルト)
NetBIOS Working Group [Page 84]
RFC 1002 March 1987
参考
[1] "Protocol Standard For a NetBIOS Service on a TCP/UDP
Transport: Concepts and Methods", RFC 1001, March 1987.
[2] J. Reynolds, J. Postel, "Assigned Numbers", RFC 990, November
1986.
[3] P. Mockapetris, "Domain Names - Implementation and
Specification", RFC 883, November 1983.
NetBIOS Working Group [Page 85]
一覧
スポンサーリンク
