第17回 LLCとNetBEUIプロトコル：基礎から学ぶWindowsネットワーク（3/3 ページ）

[デジタルアドバンテージ，著]

　LLCの概要が分かったところで、次はNetBEUIプロトコルについて見てみよう。

　「NetBEUI（NetBIOS Extended User Interface）」プロトコルは、Windowsネットワークにおける最も基本的なプロトコルであり、初期のWindowsネットワークではこれが標準的なプロトコルとして使われていた。現在ではTCP/IPをベースとするNBTに移行しているが（Active DirectoryなどはTCP/IPが必須となっている）、古いWindows NTドメインなどではまだ現役で使われている場合もあるだろう。NetBEUIは、管理の手間のかからない自己調整型のシンプルなプロトコルである。TCP/IPのように、各コンピュータにIPアドレスを（重複しないように）割り当てるといった手間が要らず、コンピュータに名前を付けてネットワークにつなぎさえすれば、それだけでお互いに通信することができるというメリットがある。もっとも最近ではTCP/IPプロトコルの開発なども進み、IPアドレスの割り当てなどで苦労することも少なくなってきたのだが。

　マイクロソフト社のドキュメントなどによると、NetBEUIは、20台から200台程度の小規模なネットワーク向きの軽量なプロトコルであるとされているが、逆にいうと、大規模なネットワークの構築には向かないプロトコルであるといえる。ほかのネットワーク・プロトコルと比べると、例えばネットワークを識別するための「ネットワーク番号」のようなアドレス付けメカニズムを持たないため、ネットワークを区別してルーティングすることができない。そのため、すべてのノードが同一のLAN上に存在している必要がある。またノード同士の通信（セッション）を識別するための番号である「セッションID」というフィールドが1byteしかないため、多くても250台程度のノードとしか通信できない。このあたりが小規模ネットワーク向きといわれる理由である。

NetBEUIの歴史

　NetBIOSは、IBM PC Networksのために開発されたネットワーク・アプリケーション向けの基本サービスAPIであり、当初はネットワーク・カードを利用するためのBIOSとして設計された（このあたりの事情については、本連載の第1回「ユーザーから見たWindowsネットワークとその舞台裏―2．Windowsネットワークの歴史」を参照していただきたい）。だがこのときに利用されていたネットワーク・プロトコルはまだNetBEUIではなく、Sytek（ネットワーク・カードのベンダ）独自のものであった。

　その後、IBMはLAN Manager Serverを開発するにあたり、NetBIOSをアプリケーションのためのインターフェイスとして下位のネットワーク・プロトコルから切り離し、Token Ringネットワーク（IEEE 802.5）上へ実装し直した。このときに決められたのがLLCを利用する、現在のNetBEUIというプロトコルである（※）。

※ 「インターフェイス」とは、アプリケーション・プログラムから利用する場合のサービスの呼び出し方法やパラメータなどの規定のこと。「プロトコル」とは、2つのノード間で通信する場合の手順やパラメータの受け渡し方法の規定のこと。インターフェイスとプロトコルの違いについては連載第2回「Windowsネットワークのレイヤ・モデルとファイル共有―１．ネットワークの基本中の基本、OSI参照モデルとは？」も参照のこと。当初のNetBIOSはプロトコルでもあるし、インターフェイス（API）でもあったが、Token Ring上に実装する際にNetBIOSはインターフェイスとして標準化され、下位のプロトコルとは独立したものになった。このときに決められたのがLLC上のNetBEUIというプロトコルである。その後NetBIOSはToken Ringだけでなく、イーサネットなどの上にも移植されたし、NetBIOS over TCP/IP（NBT）やNetBIOS over IPX/SPXなど、多くのプロトコル上にも実装されている。

　NetBEUIにはいくつかバージョンがあるが、現在ではNetBEUIをベースにしたNBF（NetBEUI Frame Format）というプロトコルが利用されている。これはNetBEUIプロトコルをWindows NT上に実装したものである。基本的には（Windows 3.x／9xなどの）NetBEUIとほぼ同じで、機能的にも互換性があるが、次のような点が異なっている。

■TDIベースでの実装
　Windows NTでは、TDI（Transport Driver Interface）というネイティブなネットワーク・サービスを持っており（DOSやWindows 3.x／9xと違って、16bitインターフェイスがネイティブではない）、TDIベースで動作するように作られている。

■セッション数制限の解除
　NetBIOSではセッション数が最大でも250程度に限定されているが（セッションIDが1byteしかないため）、セッションIDの管理方法を工夫することにより、その制限をなくし、より多くのコンピュータと同時に通信できるようにしている。

• Key Differences Between NetBEUI and NBF（Microsoft）

　このように、現在のWindows NTベースのOSでは、NetBEUIではなく、NBFというのが正しいが、特に断りのない限り本連載ではいままでどおりNetBEUIと呼ぶことにする。

NetBEUIのパケット構造

　以下にNetBEUIのパケット構造を示しておく。すでに述べたようにNetBEUIではLLCを利用しているので、NetBEUIヘッダの直前にはLLCヘッダが存在している。

NetBEUIのパケット構造
これはNetBEUIの基本的なパケット・フォーマット。※の部分は、セッション・サービスでは、16bytesのNetBIOS名ではなく、1byteのセッションIDになる。LLCのヘッダは、使用するLLCのコマンドによっても異なるので「Control」と書かれた部分の長さは1byteではなく2bytesになっていることがある。

　以下、各フィールドについて簡単に説明しておく。

■LLCヘッダ
　前ページで述べたとおり、NeBEUIはLLC上で動作するようになっているので、NetBEUIヘッダの直前にはLLCのヘッダが存在する。LLCのDSAPとSSAPにはそれぞれ0xF0（NetBIOS）がセットされる（最下位bitはほかの目的に使われるので、0xF0か0xF1のいずれかになる可能性がある）。Controlは、LLCのコマンドに応じて1byteもしくは2bytesになる可能性がある。詳細については前ページを参照。

■NetBIOSヘッダ長
　ここから先がNetBEUIプロトコルのヘッダになる。先頭にはNetBIOSヘッダ部の長さ（図中の緑色部分のサイズ）を表す値がセットされる。

■NetBIOS ID
　固定長の0xFEFFという2bytesの数値。正当なNetBEUIヘッダであることを表す数値。

■コマンド番号
　コマンドやコマンドの応答を表すコード。

■オプション・データ1／2
　コマンドに伴うパラメータを渡すためのフィールド。1byteのパラメータと2bytesのパラメータの2つがある。

■Xmit／Resp Correlator
　問い合わせやそれに対する応答の結果などを渡すためのフィールド。コマンドごとに内容は異なる。

■あて先NetBIOS名／送信元NetBIOS名
　NetBIOSパケットのあて先と送信元のノードを表すNetBIOS名をセットするフィールド。すでに何度も述べているように、NetBIOS名は最大で16文字の文字列なので、これらのフィールドはいずれも16bytesのサイズを持っている（最後の1byteはNetBIOS名のタイプを表す）。ただしセッション指向サービスでは、NetBIOS名ではなく、確立したセッションを識別するためのセッション番号（1byte）になる。セッション番号は、リモート側とローカル側でそれぞれ独立して設定される。

　パケットの構造としては、あまり複雑なものではない。基本的には、NetBIOS APIで呼びされた各種のパラメータをセットして、パケットを送信するだけである。とはいっても、ここで使われるパケットの構造やコマンド番号はNetBIOS APIのものをそのまま利用しているわけではない。NetBIOS呼び出しで渡されたパラメータのうち、例えばあて先や送信元のNetBIOS名などをパケット中にコピーし、さらに適当なコマンド番号やパラメータなどをセットしてLLC層に渡すようになっている。

　このパケット構造から分かるように、送信のあて先を指定する方法は16bytesのNetBIOS名フィールドしかない。これではルーティングは困難であろう。

NetBEUIコマンド

　具体的なNetBEUIコマンドの一覧を以下に示しておく。NetBIOSのコマンドと似てはいるが、同じではないことが分かるだろう（NetBIOSのコマンドについては、本連載の第3回「Windows LANの核心、NetBIOSを理解する（その1）―２．NetBIOSの2つのデータ通信サービス」を参照）。例えばNetBIOSで渡されたデータはそのままではネットワーク層では扱えないくらい大きい場合があるので、それらを小さく区切って（セグメント化して）分割して送信したり、バッファがオーバーしそうなときは一時停止（フロー制御）させたりするために、いくつかの細かいサブコマンドが用意されている。

	コマンド	コード	意味
	名前管理コマンド
	ADD_NAME_QUERY	0x01	登録しようとしているNetBIOS名が重複していないかどうか調査する
	ADD_GROUP_NAME_QUERY	0x00	登録しようとしているNetBIOSグループ名が重複していないかどうか調査する
	ADD_NAME_RESPONSE	0x0D	ネガティブ応答：名前が重複している。ADD_NAME_QUERYもしくはADD_GROUP_NAME_QUERYに対する応答
	NAME_IN_CONFLICT	0x02	登録しようとしている名前が重複していることを表す
	セッションの確立と終了
	NAME_QUERY	0x0A	ネットワーク上に存在する名前を問い合わせ、セッションの確立の準備をする
	NAME_RECOGNIZED	0x0E	NAME_QUERYに対する肯定応答。セッション確立の準備ができている
	SESSION_INITIALIZE	0x19	セッションの確立。NAME_RECOGNIZEDに対する応答として送信する
	SESSION_CONFIRM	0x17	SESSION_INITIALIZEに対する応答。セッションの確立が成功したことを表す
	SESSION_END	0x18	セッションの終了
	SESSION_ALIVE	0x1F	セッションがまだアクティブであることを通知する
	データの送受信
	DATA_FIRST_MIDDLE	0x15	セグメント化（フラグメント化）されたデータの送信。最初か途中のデータ・セグメントを表す
	DATA_ONLY_LAST	0x16	データの送信。完結しているデータ・セグメントか、セグメント化されたデータのうち、最後のセグメントを表す
	DATA_ACK	0x14	DATA_ONLY_LASTに対する応答
	DATAGRAM	0x08	指定された名前に対するデータグラム・データの送信
	DATAGRAM_BROADCAST	0x09	すべての名前に対するデータグラム・データのブロードキャスト送信
	NO_RECEIVE	0x1A	データの受信確認と、送信の一時停止の要請
	RECEIVE_CONTINUE	0x1C	受信の保留中の通知
	RECEIVE_OUTSTANDING	0x1B	受信の再開要請
	管理コマンド
	STATUS_QUERY	0x03	リモート・ノードのステータスの取得要請
	STATUS_RESPONSE	0x0F	STATUS_QUERYに対する応答
	TERMINATE_TRACE	0x07	リモート・ノードのトレースの中止
	TERMINATE_TRACE	0x13	ローカルとリモート・ノードのトレースの中止
NetBEUIのコマンド一覧

　NetBEUIにおける基本的な通信方法は、まずNAME_QUERY（ブロードキャスト）で通信相手を探し、見つかればSESSION_INITIALIZEでセッションを確立、DATA_FIRST_MIDDLE／DATA_ONLY_LASTでデータを送信するという手順を踏む。データグラム通信の場合は事前のセッション確立が不要なので、DATAGRAMコマンドで直接送信することができる。

　また各マシンは、自分の起動時にADD_NAME_QUERYで自分の名前を周囲にアナウンスし、通知するという手順を踏む。また誰かがNAME_QUERYを発行すれば、それが自分あてかどうかを調べ、そうならばNAME_RECOGNIZEDで応答する、というふうに動作する。このように、誰かが通信を開始しようとするたびにブロードキャストがネットワーク上へ送信されるので、「チャッティ（chatty、おしゃべり）」なプロトコルと呼ばれることもある。

NetBIOSパケットの例

　それでは簡単にNetBEUIのパケットの例を2つほど見ておこう。実際のファイル・サービスなどにおける一連のNetBIOSコマンドのやりとりは次回以降で詳しく解説するので、ここでは取り上げない。

NetBEUIの例1
指定されたNetBIOS名のコンピュータが存在するかどうかを問い合わせる「NAME_QUERY」コマンドの発行例。イーサネットのブロードキャスト送信機能を使って、NetBEUIの問い合わせパケットがネットワーク上へブロードキャスト送信されている。
　（1）下位プロトコルはLLC。LLCのUフォーマットのフレームを使っている。
　（2）NetBEUIヘッダの総サイズ。
　（3）NetBEUIの識別子。常に固定的な数値（0xEFFF）。
　（4）「NAME_QUERY」コマンドで、ある名前のコンピュータが存在するかどうかを調べている。
　（5）問い合わせ先のコンピュータ名。
　（6）NetBIOS名のリソース・タイプは「<20>（ファイル・サーバ）」。
　（7）送信元のコンピュータ名。
　（8）NetBIOS名のリソース・タイプは「<00>（ワークステーション）」。
　（9）イーサネット・パケットのあて先MACアドレスは「03-00-00-00-00-01」。これはNetBIOSマルチキャスト用の特別なMACアドレス。
　（10）パケットのダンプを見ると、NetBIOSマシン名がそのまま入っていることが分かる。

　これは、指定されたNetBIOS名のコンピュータが存在するかどうかを問い合わせる「NAME_QUERY」コマンドの発行例である。LLC上にNetBEUI（画面中では「NETBIOS」と表示されている）が実装されていることが分かるだろう。NetBEUIパケットの最後には、あて先と送信元のマシンのNetBIOS名がセットされている。それぞれの名前の最後（16bytes目）にはNetBIOS名のリソース・タイプを表す数値がセットされている。この例では、問い合わせ元のマシンでは「<00>（ワークステーション）」、問い合わせ先のマシンでは「<20>（ファイル・サーバ）」となっている。NetBIOSのリソース・タイプについては、本連載の第4回「NetBIOSを理解する（その2）―１．NetBIOS名とは何か？」を参照のこと。

　ところでこの問い合わせパケットはブロードキャストで送信されているが、そのあて先MACアドレスに注意してほしい。通常のTCP/IPのブロードキャストなどと違って、あて先MACアドレスが「FF-FF-FF-FF-FF-FF」ではなく「03-00-00-00-00-01」となっている。これはNetBIOSマルチキャスト用の特別なMACアドレスである（先頭バイトの最下位ビットが1ならブロードキャスト／マルチキャスト）。

　次はNetBEUIのセッション・サービスの例である。使用されているNetBEUIコマンドは「DATA_FIRST_MIDDLE」であり、大きなデータを分割して転送している状態が分かる。NetBIOS名ではなく、セッション番号によって送受信先が識別されている。

NetBEUIの例2
これはNetBEUIのセッション・サービスの例。「DATA_FIRST_MIDDLE」コマンドを利用して大きなデータを分割（セグメント化）して送信している。送受信先はNetBIOS名ではなく、セッション番号によって識別されている。
　（1）データの送信は、LLCのIフォーマットを使って行われる。
　（2）「DATA_FIRST_MIDDLE」コマンド。データをセグメント化して、その一部を送信する場合に利用する。最後のセグメントは「DATA_ONLY_LAST」で送信する。
　（3）リモートとローカルのセッション番号。このセッション番号はNetBEUIのセッション確立時に決定される。
　（4）NetBIOS名ではなく、セッション番号になっているので、パケット長が短くなっている。

次の回へ »

「連載 基礎から学ぶWindowsネットワーク　――　Windowsネットワーク管理者への道　――　」