第18回 NetBIOS over TCP/IPプロトコル（その1）：基礎から学ぶWindowsネットワーク（3/3 ページ）
今日、最適なWindowsネットを設計し、問題に対処するには、NetBIOS over TCP/IP（NBT）の知識が欠かせない。
NetBIOSのサービスを大きく分けると、名前解決サービス、セッション通信サービス、データグラム通信サービスの3種類がある。前回解説したNetBEUIでは、基本的には1種類のフォーマットのパケットでこれらのサービスを処理していたが、NBTでは、目的別に3種類の異なるフォーマットを採用している。これは、用途に応じて最適化された構造を採用して無駄を省くためであろう。
ここでは、これら3種類のパケット構造について解説する。
パケット形式1―名前サービス・パケット
名前サービス・パケットは、NetBIOSによるセッション通信やデータグラム通信に先立って、通信相手を特定するための、問い合わせやその応答に使われる。
すでに何度も述べているように、NetBIOSでは16bytesの「NetBIOS名」を使って通信相手やサービスを特定している。そのため前回解説したNetBEUIのパケット構造でも、送信先や送信元を特定するためにNetBIOS名というフィールドが用意されていた。
だがNBTでは16bytesといった固定長ではなく、ホスト名にドメイン名を追加した、「FQDN名」で通信相手を特定することができるように仕様が拡張されている。そのため、より長い名前を扱うことができるようにパケットの構造が可変長となっている。以下にNBTの名前サービスで利用されるパケットの構造を示しておく。
NetBIOS over TCP/IP（NBT）の名前サービス・パケットの構造
名前サービスでは、NetBEUIの場合と同様に、NetBIOS名の登録や問い合わせ、解放といった処理を行う。NBTではさらに、NetBIOS名からIPアドレスを求めるという処理も担当する。このパケット構造はDNSの問い合わせ／応答パケットと類似している。NetBIOS名前サービスは、TCP／UDPのポート137番を使用する。
これを見ると分かるように、このパケットの構造はNetBEUIの場合とは大きく異なっている。実はこれはDNSの問い合わせ／応答パケットに近い構造になっている（DNSのパケット構造については「RFC1035―DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION」参照）。NBTでは名前の扱いが単なる16bytetsのNetBIOS名ではなく、より汎用性の高いFQDN名となっているため、それに向いたパケット構造として、DNSサービスを参考にして開発されたのだろう。
以下、各フィールドについて簡単に説明しておく。
■トランザクションID
これは、名前解決サービスのパケットを識別するために利用される識別番号。名前解決サービスの基本的な動作は、問い合わせパケットの送信と、それに対する応答という形で処理が進むが、どの問い合わせに対する応答であるかを識別するためにこのIDフィールドが利用される。このIDは問い合わせパケットを送信する側でセットし、応答する側では同じIDのまま返信する。こうすることにより、応答が遅れてほかの問い合わせと順番が入れ替わったりしても、正しく送信元のアプリケーションへ応答を返すことができる。
■OPCODE（operation code）
名前解決サービスのコマンド種別を表すコード。同じパケット構造で名前解決サービスに対する要求とその応答を兼用しているため、問い合わせコマンドだけでなく応答に対してもコードが割り当てられている。具体的なOPCODEの値としては次のようなものがある。
| 数値 | OPCODE | 意味 |
|---|---|---|
| 0x00 | Query | 名前の問い合わせ。ある名前がすでにNetBIOS名として登録されているかどうかを問い合わせる |
| 0x05 | Registration | 名前の登録。コンピュータ名やサービス名、ワークグループ名などを登録するために利用する |
| 0x06 | Release | 名前の解放。登録したNetBIOS名を解放して、使用を停止する |
| 0x07 | WACK（Wait for Acknowledgement） | アクノレッジ（応答確認）を待つ |
| 0x08 | Refresh | 名前の更新要求 |
| 0x09 | Alt Refresh | 名前の更新要求（正しくは0x08を使うべきだが、RFC文書中のミスタイプにより、この0x09も0x08と同様に扱われる） |
| 0x0F | Multi-Homed Name Registration | マルチホーム・コンピュータにおける名前登録。通常は1つのIPアドレスで1つのNetBIOSコンピュータ名しか登録できないが、マルチホーム・コンピュータでは1つのコンピュータ名で複数のIPアドレスを持つことができる |
| OPCODEとその意味 5bitsのOPCODEフィールドはNetBIOS名前サービス関連のコマンドの種類を表す。下位4bitがコマンドの種類で、最上位1bitが0ならばコマンド、1ならばその応答を表す。 | ||
OPCODEフィールドは5bits幅であるが、最上位の1bitが0ならコマンド、1ならコマンドに対する応答を表し、下位の4bitが実際のコマンド・コードを表す。
■NMフラグ
名前解決サービス用の制御データが格納されたフラグ領域。例えばパケットの送信がブロードキャストかユニキャストかを区別するフラグや、データが規定長を超えたので切り詰められたかどうかを表すフラグなどがある。詳細は省略。
■RCODE（response code）
名前解決サービス・コマンドの実行結果を表すコード。コマンドごとに、その失敗の要因コードが定義されている。
■QDカウント
以下の「問い合わせエントリ」に含まれるレコードの数。
■ANカウント
以下の「応答リソース・レコード」に含まれるレコードの数。
■NSカウント
以下の「オーソリティ・リソース・レコード」に含まれるレコードの数。
■ARカウント
以下の「追加リソース・レコード」に含まれるレコードの数。
■問い合わせエントリ
名前問い合わせにおいて、問い合わせの対象となるNetBIOS名前文字列。
■応答リソース・レコード
名前問い合わせなどに対する応答のレコード。
■オーソリティ・リソース・レコード／追加リソース・レコード
これらの内容はコマンドに応じて変わる。コマンドごとのパラメータや応答コードなどがセットされる。
パケット形式2―セッション・サービス・パケット
これはセッション指向のデータ通信サービスを行うために利用されるパケットである。一度セッションが確立してしまえば、あとはデータをやりとりするだけなので、パケットの構造は非常に単純である。セッション・サービスでは送信したデータの順序性の維持（送信したとおりにデータが相手に届くこと）やエラー時の再送、通信相手の特定、セッションの維持などの処理が必要になるが、前回解説したLLC＋NetBEUIプロトコルと違って、これらはすべて下位のTCPレベルで実現される。そのためNBTヘッダには、ペイロード（データ部分）しか含まれておらず、非常にシンプルになっている。
NetBIOS over TCP/IP（NBT）のセッション・サービス・パケットの構造
セッション・サービスでは、ユーザーのデータをストリームへ送信する。セッション・パケットの信頼性（順序の保証、エラー時の再送など）は下位のTCP層で実現する。NBTのセッション・サービスは、TCPのポート139番を使用する。
以下、簡単に各フィールドについて解説しておく。
■タイプ
セッション通信サービスのコマンド種別を表すコード。具体的には以下のようなコマンドがある。
| 数値 | タイプ | 意味 |
|---|---|---|
| 0x00 | Session Message | メッセージ（セッション・データ）の送信 |
| 0x81 | Session Request | セッション開始要求 |
| 0x82 | Positive Session Response | セッション開始要求への肯定応答 |
| 0x83 | Negative Session Response | セッション開始要求への否定応答 |
| 0x84 | Retarget Session Response | セッション開始要求へのリダイレクト応答 |
| 0x85 | Session Keep Alive | セッションのキープアライブ（維持）要求 |
| セッション通信サービスのコマンド一覧 Session Requestでセッションの開始を要求し、認められれば（Positive Session Responseが戻ってきたら）、Session Messageでセッション・データを送信する。 | ||
■データ長
NetBIOSデータ部の長さ。最大で64Kbytesまでのデータを送信することができる。
■オプション・データ
コマンドごとのオプション・パラメータのデータ。この部分の詳細はコマンドごとに異なる。例えば「Session Request（セッション開始の要求）」コマンドでは、呼び出す側と呼び出される側のサービスを表すNetBIOS名が含まれるし、「Negative Session Response（セッション開始要求への否定応答）」では、セッション開始要求がエラーとなった原因を表すエラー・コードなどが含まれる。
パケット形式3―データグラム・サービス・パケット
これはNetBIOSデータグラム通信サービスのために利用されるパケットである。データグラム通信では、あるひとかたまりのデータ・ブロックを相手に届けるだけであり、エラー発生時の再送処理や送信順序の保証などは行わない。そのため、単にUDPパケット上にデータ・ブロックを載せて、通信の相手先ノードへ届けるだけでよい。データグラム通信の機能や信頼性は、下位のUDPパケット（およびその下位のIPパケット）と同様である。ネットワークの混雑具合によっては、相手に届かないこともあるし、送信した順番どおりに到着しないこともある。
以下にNBTのデータグラム・サービスのパケット構造を示しておく。
NetBIOS over TCP/IP（NBT）のデータグラム・サービス・パケットの構造
データグラム・サービスでは、ユーザーのデータを指定されたあて先へ送信するが、受信確認などは行わない。下位のUDPと同じ程度の信頼性を確保する。NBTのデータグラム・サービスは、UDPのポート138番を使用する。
■タイプ
データグラム通信サービスのコマンド種別を表すコード。具体的には以下のようなコマンドがある。
| 数値 | タイプ | 意味 |
|---|---|---|
| 0x10 | Direct Unique Datagram | 単一ホストあてのデータグラム送信（ユニキャスト送信） |
| 0x11 | Direct Group Datagram | 特定のグループあてのデータグラム送信（マルチキャスト送信） |
| 0x12 | Broadcast Datagram | データグラムのブロードキャスト（ブロードキャスト送信）。ローカル・ネットワーク上のすべてのコンピュータに対して同報送信する |
| 0x13 | Datagram Error | データグラム送信要求に対するエラー応答 |
| 0x14 | Datagram Query Request | データグラム問い合わせ要求。NetBIOSのデータグラムを中継・展開するサーバ（NBDD：NetBIOS Datagram Distributionサーバ）に対する問い合わせで利用される |
| 0x15 | Datagram Positive Query Response | 問い合わせ要求に対する肯定応答 |
| 0x16 | Datagram Negative Query Response | 問い合わせ要求に対する否定応答 |
| セッション通信サービスのコマンド一覧 最初の3つのいずれかのコマンドを使ってデータグラム・データを送信する。 | ||
以下、簡単に各フィールドについて解説しておく。
■フラグ
各種の制御用フラグ。フラグ中には、NetBIOSのノード・タイプ（次回解説予定）や、データグラムのフラグメント状態を表すF／M（First／More）bitが含まれている。NetBIOSで送信するデータが下位のUDPの制限パケット・サイズを超えるような場合、データをいくつかのデータグラム・パケットに分割して送信する。これをフラグメントという。フラグメント化されたパケットのうち、最初にパケットではF bitを1にして、これが先頭のパケットであることを表す。また最後のパケットでない場合は、M bitを1にして、後続のフラグメント・パケットが存在することを表す。
■データグラムID
送信するデータグラムを識別するための任意のID番号。送信側が任意に割り当てるが、フラグメント化されたパケットでは同一のデータグラムIDを共有し、もともとは同一のデータグラムに属していたことを表す。
■ソースIP
データグラムの送信元IPアドレス。
■ソース・ポート番号
データグラムの送信元のポート番号。
■データグラム長
以下のNetBIOSデータ部分の長さ。
■パケット・オフセット
フラグメント化されたパケットにおいて、データグラムのどの部分のフラグメントであるかを表すために利用される。フラグメント化されていない場合は0となる。
■NetBIOSデータ
データグラムとして送信するデータ。ただし先頭部分には、データグラムの送信元NetBIOS名およびあて先NetBIOS名がエンコードされた状態で格納され、ユーザーのデータはその直後（「パケット・オフセット」の位置）から始まる。ユーザーのデータ（データグラムとして相手に送信されるデータ）は最大で512bytesまでとなっている。
今回は、NBTパケットの概要と、パケットの構造について解説した。次回は、より詳細なNetBIOSの通信例や、NBTにおける名前解決の各種の方法について解説する。
Copyright© Digital Advantage Corp. All Rights Reserved.