Network Working Group Request for Comments: 1001 March, 1987 TCP/UDP トランスポート上における NetBIOS サービスのためのプロトコル標準: コンセプトと方式 概要 この RFC では、 TCP/IP 環境において NetBIOS サービスをサポートするため に提案されたプロトコル標準について定義している。ローカルネットワークと インターネット経由の処理(operation)の両方がサポートされる。ローカルお よびインターネットのトポロジに対応し、IP ブロードキャストの利用可否に 関わらず、処理を可能にするため、各種のノードタイプが定義されている。 この RFC では、NetBIOS over TCP/IP プロトコルの概略について、特にその 思想(underlying idea)と手法(technique)を中心に据えて記述している。 仕様の詳細については、関連する RFC の「Protocol Standard For a NetBIOS Service on a TCP/UDP Transport: Detailed Specifications」に記述されている。 NetBIOS Working Group [Page 1] RFC 1001 March 1987 概要の目次 1. この記述の位置付け 6 2. 謝辞 6 3. はじめに 7 4. 設計の原則 7 5. NetBIOS の概要 10 6. この標準がサポートする NetBIOS の機能 15 7. 必要なサービスインタフェースと定義 15 8. 関連するプロトコルとサービス 16 9. NetBIOS スコープ 16 10. NetBIOS 終端ノード 16 11. NetBIOS サポートサーバ 18 12. トポロジ 20 13. 一般的な処理手順 23 14. NetBIOS 名の表記法 25 15. NetBIOS ネームサービス 27 16. NetBIOS セッションサービス 48 17. NETBIOS データグラムサービス 55 18. ノード設定パラメータ 58 19. 最低限の条件 59 参照 60 付録 A - Internet Group Multicast との連携 61 付録 B - 実装についての考察 62 NetBIOS Working Group [Page 2] RFC 1001 March 1987 目次 1. この記述の位置付け 6 2. 謝辞 6 3. はじめに 7 4. 設計の原則 8 4.1 NetBIOS サービスの互換性 8 4.2 存在している標準の活用 8 4.3 オプション数の低減 8 4.4 エラーや障害に対応できる 8 4.5 一元的な管理を必要としない 9 4.6 インターネット環境への対応 9 4.7 ブロードキャスト処理の低減 9 4.8 現存するシステムへの実装可否 9 4.9 最低限の機能のみを要求する 9 4.10 最大限の効率化 10 4.11 新規機能の削減 10 5. NetBIOS の概要 10 5.1 アプリケーションプログラムに対するインタフェース 10 5.2 ネームサービス 11 5.3 セッションサービス 12 5.4 データグラムサービス 13 5.5 その他の機能 14 5.6 非標準の拡張 15 6. この標準がサポートする NetBIOS の機能 15 7. 必要なサービスインタフェースと定義 15 8. 関連するプロトコルとサービス 16 9. NetBIOS スコープ 16 10. NetBIOS 終端ノード 16 10.1 ブロードキャスト (B) ノード 16 10.2 ポイントツーポイント (P) ノード 16 10.3 混在モード (M) ノード 16 11. NetBIOS サポートサーバ 18 11.1 NetBIOS ネームサーバ (NBNS) ノード 18 11.1.1 NBNS と DNS との関係 19 11.2 NetBIOS データグラム配布サーバ (NBDD) ノード 19 11.3 NBNS と NBDD ノードの関係 20 11.4 NetBIOS サポートサーバと B ノードとの関係 20 12. トポロジ 20 12.1 ローカル環境 20 NetBIOS Working Group [Page 3] RFC 1001 March 1987 12.1.1 B ノードのみ 21 12.1.2 P ノードのみ 21 12.1.3 B および P ノードの混在環境 21 12.2 インターネット環境 22 12.2.1 P ノードのみ 22 12.2.2 M ノードと P ノードの混在環境 23 13. 一般的な処理手順 23 13.1 リクエスト/レスポンス 処理の手順 23 13.1.1 リクエストの再送 24 13.1.2 レスポンスのないリクエスト: 要請 (DEMAND) 24 13.2 トランザクション 25 13.2.1 トランザクション ID 25 13.3 TCP ベースと UDP ベース 25 14. NetBIOS 名の表記法 25 14.1 第 1 レベルのエンコーディング 26 14.2 第 2 レベルのエンコーディング 27 15. NetBIOS ネームサービス 27 15.1 NetBIOS ネームサービスの概要 27 15.1.1 名前の登録 (CLAIM) 27 15.1.2 名前の問い合わせ (DISCOVERY) 28 15.1.3 名前の解放 (RELEASE) 28 15.1.3.1 明示的な解放 28 15.1.3.2 名前の有効期限と更新 29 15.1.3.3 名前の確認 29 15.1.3.4 グループ名の消滅 29 15.1.3.5 名前の競合 30 15.1.4 アダプタステータス 31 15.1.5 終端ノードの NBNS 処理 31 15.1.5.1 UDP, TCP および切り詰め(truncation) 31 15.1.5.2 NBNS WACK 32 15.1.5.3 NBNS 転送 32 15.1.6 セキュアな NBNS と非セキュアな NBNS 32 15.1.7 NBNS データベースの一貫性 32 15.1.8 名前のキャッシュ 34 15.2 名前登録のトランザクション 34 15.2.1 B ノードによる名前登録 34 15.2.2 P ノードによる名前登録 35 15.2.2.1 新規の名前、新規のグループメンバ 35 15.2.2.2 既存の名前で、所有者も動作している場合 36 15.2.2.3 既存の名前で、所有者が動作していない場合 37 15.2.3 M ノードによる名前登録 38 15.3 名前問い合わせのトランザクション 39 15.3.1 B ノードによる問い合わせ 39 15.3.2 P ノードによる問い合わせ 40 15.3.3 M ノードによる問い合わせ 43 15.3.4 グループのメンバ一覧の取得 43 15.4 名前解放の処理(トランザクション) 44 15.4.1 B ノードによるリリース 44 NetBIOS Working Group [Page 4] RFC 1001 March 1987 15.4.2 P ノードによるリリース 44 15.4.3 M ノードによるリリース 44 15.5 名前維持の処理 45 15.5.1 名前の更新 45 15.5.2 名前のチャレンジ 46 15.5.3 名前の競合の解決 47 15.6 アダプタステータス処理 47 16. NetBIOS セッションサービス 48 16.1 NetBIOS セッションサービスの概要 49 16.1.1 セッション確立フェーズの概要 49 16.1.1.1 「呼出先変更」後の再試行 50 16.1.1.2 グループ名に対するセッションの確立 51 16.1.2 確立状態フェーズの概要 51 16.1.3 セッション終了フェーズの概要 51 16.2 セッション確立フェーズ 52 16.3 セッションデータ転送フェーズ 54 16.3.1 データのカプセル化 54 16.3.2 session keep alive 54 17. NETBIOS データグラムサービス 55 17.1 NetBIOS データグラムサービスの概要 55 17.1.1 ユニキャスト、マルチキャスト、ブロードキャスト 55 17.1.2 NetBIOS データグラムのフラグメンテーション 55 17.2 B ノードにおける NetBIOS データグラム 57 17.3 P ノードや M ノードにおける NetBIOS データグラム 58 18. ノード設定パラメータ 58 19. 最低限の条件 59 参考 60 付録 A 61 Internet Group Multicastion との連携 61 A-1. B および M ノードに必要なプロトコル 61 A-2. 制限事項 61 付録 B 62 実装についての考察 62 B-1. 実装モデル 62 B-1.1 モデルに依存しない考察 63 B-1.2 各モデルのサービス処理 63 B-2. 一般 NetBIOS アプリケーションと特権 NetBIOS アプリケーション 64 B-3. TCP の利用と Keep Alive 66 B-4. 「呼出先変更」アルゴリズム 67 B-5. NBDD サービス 68 B-6. アプリケーションに関する考察 68 B-6.1 NetBIOS データグラムの利用 68 NetBIOS Working Group [Page 5] RFC 1001 March 1987 PROTOCOL STANDARD FOR A NetBIOS SERVICE ON A TCP/UDP TRANSPORT: CONCEPTS AND METHODS 1. この記述の位置付け この RFC では、インターネットのコミュニティに対して提案された標準に ついて記述されている。本題は、インターネットコミュニティにとって新 しいものであるため、討議や提案を特に要求したい。 紙ベースのコメントは、以下に送付してほしい: Karl Auerbach Epilogue Technology Corporation P.O. Box 5432 Redwood City, CA 94063 オンラインでのコメントは、以下に送付してほしい: Avnish Aggarwal Internet: mtxinu!excelan!avnish@ucbvax.berkeley.edu Usenet: ucbvax!mtxinu!excelan!avnish このドキュメントの配布は制限されない。 2. 謝辞 この RFC は、Internet Activities Board 、特に End-to-End Services Task Force の支援によって作成された。 以下の者が、この 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 この RFC によって提案された仕組みは、既存の NetBIOS over TCP の実装 を反映したものではない。しかし、設計にあたっては、既存の実装から得 た多くの知識を反映している。これらの貴重な情報を提供していただいた 以下の組織には、特に感謝する: CMC/Syros Excelan Sytek Ungermann-Bass NetBIOS Working Group [Page 6] RFC 1001 March 1987 3. はじめに この RFC では、 TCP や UDP 上で NetBIOS を提供するための思想と共通 的な方式について記述する。関連する RFC の「Protocol Standard For a NetBIOS Service on a TCP/UDP Transport: Detailed Specifications」[1] において、パケットのフォーマット、プロトコル、定義された定数や変数 についての詳細な記述が行なわれている。 NetBIOS サービスは、パーソナルコンピュータのネットワーキングにおけ る代表的な仕組みとなっている。NetBIOS は IBM Personal Computer (PC) およびその互換機に対して、ベンダ非依存のインタフェースを提供してい る。 NetBIOS は、プロトコルではなくソフトウェアのインタフェースを定義し たものである。「公式な」NetBIOS サービスの標準は存在しない。しかし、 事実上 IBM PC-Network 版がリファレンスとして用いられている。これに ついては、IBM のドキュメント 6322916 「Technical Reference PC Network」[2]に記述されている。 NetBIOS サービスを提供するプロトコルは、多くのプロトコルやハードウェ ア上に実装されている。異なる実装間では、たとえ下位層が同じ場合であっ ても、共通のプロトコルを利用しない限りは相互接続を行なうことができな いであろう。インターネット上で NetBIOS の相互接続を行なうために、こ の RFC では TCP や UDP を用いて NetBIOS サービスをサポートするプロ トコル標準について定義する。 現在のところ、 NetBIOS の利用はパーソナルコンピュータに限られている。 しかし、大型のコンピュータの方が、ファイルサーバのような、ある種の NetBIOS アプリケーションを実行するのに適している場合も多いため、こ の規格は TCP/IP プロトコルが利用可能なシステムであれば、どのような システムであっても実装が可能な設計になっている。 この標準では、 NetBIOS サービスをサポートするプロトコル群を定義する。 これらのプロトコルは、 2 つのノード(entity)間での簡単な通信を行なう だけでのものではない。ここでの記述は、特定の NetBIOS コネクションの 通信先(end-point)となっていないノードも含め、多くのノードがそれぞれ 役割を持って機能している分散システムについてのものである (訳注: 当 時は通信というとピアツーピアの意識が強かったための補足である)。 この標準は、アプリケーションプログラムがサービスを呼び出す方式につ いて規定を行なうものでも、制限を行なうものでもない。 ただし、以下の記述は、現在 NetBIOS インタフェースが実装されている PC-DOS や MS-DOS オペレーティングシステムが実行されているコンピュー タを想定したものとなっている。 注意: この文書では、様々なシンボル値が用いられている。これらの定義 については、 Detailed Specifications[1] を参照のこと。 NetBIOS Working Group [Page 7] RFC 1001 March 1987 4. 設計の原則 規格を作成するにあたり、以下の設計の原則が指針として採用された。そ の多くはプロトコルの標準化で一般的なものであるが、一般的でない優先 順位づけがされているものも幾つか存在する。 4.1. NetBIOS サービスの互換性 NetBIOS サービスの「公式」な標準はないため、IBM PC Network Technical Reference[2] に記載されているものを採用する。 NetBIOS は、現存するアプリケーションの大部分の基盤となっている。こ れらのアプリケーションが TCP ネットワーク上でも動作し、パーソナルコ ンピュータだけでなく大型のホストにも展開できることが望ましい。 これらのアプリケーションをサポートするため、NetBIOS on TCP では、 現存する NetBIOS システムが提供するサービスとの親和性が必須である。 IBM PC-Network NetBIOS には、実装に依存した機能がある。この標準では これらの機能との完全な互換性を実現することは考えていない。現存する アプリケーションのあるものは、これらの機能を必要としており、この RFC にしたがった NetBIOS サービス上では正しく動作しないであろう。 4.2. 存在している標準の活用 プロトコルの開発、特に標準化は労力を要する作業である。新しいプロト コルの開発は、最低限にとどめることが必須である。 特に重要なことは、必要な機能を妥当な性能で提供している標準がすでに 存在しているのであれば、新しいプロトコルの開発よりは、標準の採用を 常に優先するということである。 標準のプロトコルを用いる場合、それを修正しないことが必須である。 4.3. オプション数の低減 NetBIOS on TCP の標準に含めるオプションは、もしあっても、必要最低限 にとどめるべきである。 オプションを含める場合、異なったオプションを設定したデバイス同士で も相互接続が可能なように、オプションを設計する必要がある。 4.4. エラーや障害に対応できる NetBIOS ネットワークは、通常一元的な管理が行なわれていない環境で用 いられる。コンピュータが同時にオンラインになることもあれば、何の通 告もなしにオフラインになることもしばしばである。ネットワークに関す る知識がなく、突然設定を変更してしまうかも知れないようなユーザがソ フトウェアを操作することもしばしばである。 こうした混乱があっても、NetBIOS ネットワークは動作する。NetBIOS on NetBIOS Working Group [Page 8] RFC 1001 March 1987 TCP は、こうした環境でもきちんと動作することが必須である。 堅牢な動作とは、ネットワークがありとあらゆる障害に対応できることを 意味しているものではない。NetBIOS ネットワークでは、悪意の有無に関 わらず、ある種の操作によって障害が発生することがある。 4.5. 一元的な管理を必要としない NetBIOS on TCP は、必要な場合、TCP ベースのネットワークで通常必要と される一元的な管理なしでも動作する必要がある。 4.6. インターネット環境への対応 提案されている標準では、ネットワーク(IP)レベルでの中継装置(ゲートウェ イ)によって接続されたネットワーク間での NetBIOS の処理に対する必要 性が認識されている。 ただし、この標準では、こうした処理の頻度がローカルな MAC アドレスで ブリッジされた LAN 内の処理より少ないという状態を前提としている。 4.7. ブロードキャスト処理の低減 この標準では、UDP でサポートするのはブロードキャストのみであること を前提としている。マルチキャスト機能はいかなる場合でも利用できない ことを前提としている。 この標準では、ブロードキャスト機能の利用可否に関わらず、管理者によっ ては負荷のかかるブロードキャストは極力避けたいと考えていることを認 識している。管理者としては、通信と無関係なホストが、破棄するだけの NetBIOS ブロードキャストを受信する負荷をなくしたいと考えるであろう。 4.8. 現存するシステム上への実装可否 NetBIOS on TCP プロトコルは、Unix(tm) や VAX/VMS(tm) といった、一般 的なオペレーティングシステムに対しても、それほど労力を掛けずに実装 できる必要がある。 NetBIOS プロトコルは、現在の TCP/UDP/IP の実装に通常存在しないサー ビスを必要とするものであってはならない。 4.9. 最低限の機能のみを要求する プロトコルの定義では、、相互接続に必要な最低限のプロトコル群のみを 定義する。ただし、機能向上のため、それ以外のプロトコルについても定 義することはある。後者については、通常送信側がオプションとして指定 し、すべての受信側がそれを解釈できることが必須となる。 NetBIOS Working Group [Page 9] RFC 1001 March 1987 4.10. 最大限の効率化 利便性を高めるため、プロトコルは速やかに処理を行うことが必須である。 4.11. 新規機能の削減 すでに存在しているプロトコルが必要な機能を提供してはいないものの、 多少の修正で提供可能な場合は、そのプロトコルを利用すべきである。 その方が、新しいプロトコルを開発するよりは容易であると考えられるだ けでなく、インターネット上で一般的なユーティリティの活用も可能にな る。 5. NetBIOS の概要 この章では、 NetBIOS サービスについて説明するが、ここでは背景となる 情報についてのみ説明する。この章を飛ばして次の章に進んでも構わない。 NetBIOS はブロードキャスト媒体を共有する PC 群による利用を想定して 設計された。コネクション(セッション)型とコネクションレス(データグラ ム)型の両方のサービスが提供されており、ブロードキャストやマルチキャ ストがサポートされている。通信対象は名前で識別される。名前の割り当 ては分散的に行なわれ、非常に動的なものである。 NetBIOS アプリケーションは、 NetBIOS 機構を使ってリソースの位置を特 定し、コネクションを確立して、アプリケーション間でデータの送受信を 行ない、最後にコネクションを切断する。説明のため、これらの機構をま とめて NetBIOS サービスと呼称する。 このサービスは様々な方式で実装することが可能である。最初の実装の 1 つが、 PC-DOS や MS-DOS オペレーティングシステムが実行されているパー ソナルコンピュータ用のものであった。NetBIOS を他のオペレーティング システムに実装することや、NetBIOS をホストとなるオペレーティングシ ステムからみた場合に、単なるアプリケーションプログラムのプロセスと してみえる形で実装することも可能である。 NetBIOS の仕様は、IBM から出版されている「Technical Reference PC Network」[2] でNetBIOS ユーザが利用可能なインタフェースとサービスの 形で定義されている。このドキュメントで概説されているプロトコルは、 IBM PC Network 以外を考慮しておらず、そのままで他のネットワークに適 用できるものではない。 5.1. アプリケーションプログラムに対するインタフェース パーソナルコンピュータ上の NetBIOS には、サービスおよびサービスのた めのプログラムインタフェースの両方が含まれる。 他のコンピュータシス テム上の NetBIOS では、違ったインタフェースを使うプログラムのための NetBIOS サービスが存在するかも知れない。パーソナルコンピュータ以外 で、 NetBIOS のソフトウェアインタフェースの明確な標準は存在しない。 NetBIOS Working Group [Page 10] RFC 1001 March 1987 5.2. ネームサービス NetBIOS のリソースは名前によって参照される。低レベルなアドレス情報 は NetBIOS アプリケーションから利用できない。リソースを提供するアプ リケーションは、利用したい名前を 1 つ以上登録する。 名前空間は、フラットな 16 文字の英数字からなる。名前はアスタリスク (*)から始まってはならない。 登録は、名前を利用するための手続きである。この手続きは排他的 (ユニー ク) もしくは共有される所有権を取得するために行なわれる。各アプリケー ションは、他のアプリケーションに対して登録の要求を行なう。反対がな かった場合は、ステーションに対して暗黙の許可が与えられる。つまり、 手続きが開始されると、アプリケーションは一定期間待機し、反対がなかっ た場合、そのステーションは登録の許可を得たものとみなす。 ユニーク名は、ある時点で 1 台のステーションによってのみ所有される。 ただし、問題発生時には、重複 (「名前の競合」)が発生することもある。 グループ名を登録している各ステーションはすべて平等である。 ある名前を参照するアプリケーションは、通常その名前がユニーク名かグ ループ名かを認知しない(意識しない)。 明示的に名前の削除を行なうことで、アプリケーションは名前を削除する。 ステーションが動作を停止すると、暗黙の名前の削除が行なわれる。パー ソナルコンピュータの場合、暗黙の名前の削除は頻繁に発生する。 ネームサービスの命令には以下のものがある: 1) Add Name アプリケーションは、名前の排他的な利用を要求する。 2) Add Group Name アプリケーションは、他のアプリケーションと共有しての名前の 利用を要求する。 3) Delete Name アプリケーションは、その名前の利用をこれ以上要求しない。 想定される NetBIOS の環境は、独立して動作するパーソナルコン ピュータの環境であることに注意してほしい。 PC を停止させる 一般的な方法は、 PC の電源をオフにすることであり、こうした ケースでは、Delete Name の提供する通知の仕組みは使われない。 こうしたケースは頻繁に発生しうるため、ネットワークサービス は、こうしたケースをサポートすることが必須である。 NetBIOS Working Group [Page 11] RFC 1001 March 1987 5.3. セッションサービス セッションは、NetBIOS アプリケーション間で行なわれる、信頼できるメッ セージの交換である。セッションは全二重であり、順序性があり、信頼で きる。データはメッセージとして扱われる。各メッセージは 0 から 131,071 バイトの範囲の大きさである必要がある。優先されるデータや緊急データ といった概念は存在しない。 呼出元と呼出先の名前の組は、いくつ存在してもよい。 接続の呼出先は、呼出元と呼出先の名前を通知される。 NetBIOS の仕様では、グループ名に対する接続の要求があった場合、どの ようなセッションを形成するかについては定義されていない。一般的な解 釈は、呼出先のグループ名のいずれかの所有者とセッションを開始すると いうものである。 NetBIOS アプリケーションによって提供される重要なサービスに、セッショ ン切断の検出がある。セッションの切断は、そのセッション上で行なわれ ていたすべての実行中のリクエストからアプリケーションに通知される。 例えば、アプリケーションが NetBIOS の Receive 命令のみを実行してい る際に、セッションが切断された場合、実行中の Receive 命令は切断の通 知と同時に中断される。 セッションサービスの命令(primitive)には以下のようなものがある: 1) Call 指定した名前で待ち受け中のプロセスに対するセッションを開始 する。呼出元は、呼出元の名前(すでに呼出元によって登録されて いる)と呼出先の名前を提示することが必須である。 2) Listen 呼出元からのセッションを待ち受ける。Listen 命令は特定の呼出 元からの呼出のみを待ち受けることもできる。逆に、呼出は、ど の呼出元から行なってもよい。 3) Hang Up セッションを適切に(gracefull)終了させる。すべての処理中のデー タはセッションが終了する前に転送される。 4) Send メッセージを 1 つ転送する。タイムアウトが発生する場合もある。 セッションのタイムアウトが発生した場合は、セッションが不適 切に(non gracefully)終了する。 NetBIOS Working Group [Page 12] RFC 1001 March 1987 「chain send」は、PC NetBIOS ソフトウェアインタフェースが必 要とする命令であり、複数のバッファにあるデータを 1 つのメッ セージにまとめて転送するものである。「chain send」は、イン タフェースレベルの命令であり、プロトコルには影響しない。 5) Receive データを受信する。タイムアウトが発生する場合もある。タイム アウトが発生した場合は、単に Receive が終了するのみであり、 セッションは終了しない。ただし、データは消失する。 Receive 命令には、 PC NetBIOS ソフトウェアインタフェースが 必要とする「Receive Any」のように幾つかの実装が可能である。 「Receive Any」はインタフェースレベルの命令であり、プロトコ ルには影響しない。 6) Session Status 指定された名前に関するすべてのセッションの情報を取得する。 ネットワークの状況は含まれない。 5.4. データグラムサービス データグラムサービスは信頼性がなく、順序性がない、コネクションレス のサービスである。データグラムは送信元によって適切に登録された名前 を含めて送信される。 データグラムは特定の名前に対して送信されることも、明示的にブロード キャストされることもある。 ユニーク名に対して送信されたデータグラムは、その名前の所有者によっ て受信される。グループ名に対して送信されたデータグラムはその名前の 所有者すべてにマルチキャストされる。送信元のアプリケーションプログ ラムはグループ名とユニーク名との違いを識別できないため、ブロードキャ ストでないデータグラムはマルチキャストとして扱うことが必須である。 セッションサービスと同様に、データグラムの受信者は、送信元と送信先 の名前を通知される。 データグラムサービスの命令には以下のようなものがある: 1) Send Datagram 信頼性のないデータグラムを指定された名前に対応するアプリケー ションに対して送信する。名前はユニーク名でもグループ名でも よく、送信者は関知しない。名前がグループ名の場合、各メンバー がデータグラムを受信する。 NetBIOS Working Group [Page 13] RFC 1001 March 1987 2) Send Broadcast Datagram 信頼性のないデータグラムを Receive Broadcast Datagram 命令 を発行している任意のアプリケーションに対して送信する。 3) Receive Datagram 明示された送信元の名前から指定された名前に対して送信された データグラムを受信する。もし送信元の名前がアスタリスクの場 合、データグラムは任意の名前を送信元とみなすことができる。 注意: 到着したデータグラムは、送信元と送信先がデータグラム のものと合致する Receive Datagram 命令を発行しているアプリ ケーションすべてが受信する。言い替えると、プログラム(または プログラム群)が同一の Receive Datagram 命令を幾つか発行して いた場合、 1 つのデータグラムによりそれらの命令すべてが完了 するということである。 4) Receive Broadcast Datagram ブロードキャストとして送信されたデータグラムを受信する。 複数の Receive Broadcast Datagram 命令が実行中の場合、単一 のデータグラムを受信することで、すべての命令が完了すること になる。 5.5. その他の機能 以下の機能はネットワークのハードウェアインタフェースに対する操作を 行なう為に存在している。これらの機能は一般的に実装依存のものである。 1) Reset ローカルのネットワークアダプタを初期化する。 2) Cancel 実行中の NetBIOS の処理を中断させる。Send (もしくは Chain Send) 処理の Cancel が成功した場合、該当するセッションも終 了させられる。 3) Adapter Status ローカルのネットワークアダプタ、もしくはリモートのアダプタ に関する情報を取得する。 4) Unlink Remote Program Load (RPL) を利用した際、 PC のブートディス クデバイスをローカルディスクに復帰させる。RPL および Unlink NetBIOS Working Group [Page 14] RFC 1001 March 1987 命令に対する詳細は、 NetBIOS の仕様を参照のこと ([2] の 2-35 ページ)。 5) Remote Program Load Remote Program Load (RPL) は NetBIOS の機能ではない。これは IBM が独自の NetBIOS の仕様として定義したアプリケーションで ある ([2] の 2-80 から 2-82 ページを参照のこと)。 5.6. 非標準の拡張 IBM の Token Ring 上の NetBIOS の実装では、少なくとも 1 つの新しい 機能が追加されている。 1) Find Name この機能は、指定された名前がネットワーク上に登録されている かどうかを確認する。 6. この標準がサポートする NetBIOS の機能 この標準で定義されたプロトコルでは IBM の「Technical Reference PC Network」[2] で記述された NetBIOS サービスのすべてを実装することも 可能である。 以下の NetBIOS の機能は、この仕様の対象外である。これらはローカルな 実装の問題であり、接続性には影響しない。 - RESET - SESSION STATUS - UNLINK - RPL (Remote Program Load) 7. 必要なサービスインタフェースと定義 この RFC で記述されたプロトコルは、以下のプロトコルに対するサービス インタフェースが必要である: - TCP[3,4] - UDP[5] バイト順、アドレス変換 (ブロードキャストやマルチキャストに利用する アドレスも含まれる) は、以下のドキュメントの最新のバージョン中で定 義されている: - Assigned Numbers[6] それ以外の定義と制約は、以下で記述されている: NetBIOS Working Group [Page 15] RFC 1001 March 1987 - IP[7] - Internet Subnets[8,9,10] 8. 関連するプロトコルとサービス この RFC で記述されたプロトコルの設計は、以下のプロトコルやサービス との将来的な連携を可能としている。 ただし、その前には、この RFC で定義されたプロトコルか、以下のプロト コルやサービスのいずれかに拡張が行なわれる必要があるだろう。 - DNS [11,12,13,14] - Internet Group Multicast[15,16] 9. NetBIOS スコープ 「NetBIOS スコープ」とは、互いに登録した NetBIOS 名を認識可能なコン ピュータ群を意味する。 NetBIOS のブロードキャストかマルチキャストの データグラムは、 NetBIOS スコープ全体に到達可能であることが必須であ る。 インターネットでは、複数の重複しない NetBIOS スコープが存在するかも 知れない。 各 NetBIOS スコープには「スコープ識別子」が存在する。この識別子は DNS で扱われるドメイン名の形式に準拠した文字列である。 注意: NetBIOS over TCP の各実装では、利用するスコープ識別子を管理す るための何らかの機構を提供することが必須である。 スコープ識別子の制御は、複数の NetBIOS インタフェース機能を実現する ために必要なものである。これは、ユーザサービスインタフェースや、そ の他の方法 (ノードの設定パラメータなど) で提供することができる。こ れらの拡張に関する詳細については、この仕様で扱う対象ではない。 10. NetBIOS 終端ノード 終端ノード(end-node)とは、 NetBIOS サービスインタフェースをサポート し、アプリケーションを含む存在である。 この標準では、以下の 3 タイプの終端ノードを規定する: - ブロードキャスト (B) ノード - ポイントツーポイント (P) ノード - 混在モード (M) ノード ある IP アドレスは上記タイプのいずれかひとつに対して割り当てられる。 あらかじめロードされた名前とアドレスの変換テーブルが存在しない場合、 NetBIOS Working Group [Page 16] RFC 1001 March 1987 NetBIOS が有効なノードは、動的に名前の解決を行なう必要がある。これ はブロードキャストか、間接的にポイントツーポイントの通信を経由して 行なわれる。 B ノードは、受信先を特定するのに、ローカルネットワークに対するブロー ドキャストを用いる。P および M ノードは、これに NetBIOS Name Server (NBNS) および NetBIOS Datagram Distribution Server (NBDD) を用いる。 終端ノードでは、複数の手段を利用しても構わない。ただし、どのような 手段を利用しても、B, P, M ノードの処理が変わることはない。 注意: M および B ノードが同じスコープに存在しないようにするため、 NetBIOS スコープの管理を行なうことを推奨する。1 つの NetBIOS スコープには B ノードのみか、P および M ノードのみを所属させ るべきである。 10.1. ブロードキャスト (B) ノード ブロードキャスト (B) ノードは UDP データグラム (ブロードキャストと ユニキャストの両方)と TCP コネクションの両方を用いて通信を行なう。 B ノードは同一ブロードキャスト領域内の他のノードと自由に通信を行な うことができる。ブロードキャスト領域とは、MAC アドレスレベルでブリッ ジされた単一の「B-LAN」である (Internet Group Multicast を、単一の B-LAN に代わる拡張されたブロードキャスト領域として用いることについ ての議論については、補足 A を参照のこと)。 10.2. ポイントツーポイント (P) NODES ポイントツーポイント (P) ノードはユニキャストの UDP データグラムと TCP セッションのみを用いて通信を行なう。P ノードがブロードキャスト される UDP パケットを送受信することはない。ただし、P ノードは NBNS および NBDD が提供する機能を利用して、NetBIOS レベルでのブロードキャ ストおよびマルチキャストのサービスを提供する。 P ノードは NBNS および NBDD に依存している。これらのサーバは、ロー カルとリモートのいずれにあっても良い。 P ノードの処理はどちらの場合 でも変わりはない。 10.3. 混在モード (M) ノード 混在モード (M) ノードは、幾つかの B ノードの特徴を持った P ノードで ある。M ノードはブロードキャストとユニキャストの両方を用いる。ブロー ドキャストを用いるのは、ほとんどのリソースが、インターネット上のど こかではなく、ローカルブロードキャスト上に存在すると仮定した場合に、 レスポンスタイムを向上させるためである。 M ノードは NBNS と NBDD サーバに依存している。ただし、 M ノードは、 万一、これらのサーバが一時的に利用できない時であっても、一部の処理 を行なうことが可能である。 NetBIOS Working Group [Page 17] RFC 1001 March 1987 11. NetBIOS サポートサーバ この標準では、 2 つのタイプのサポートサーバが定義されている: - NetBIOS ネームサーバ (NBNS) ノード - NetBIOS データグラム配布 (NBDD) ノード NBNS および NBDD ノードは NetBIOS アプリケーションが意識することは なく、下位層の NetBIOS 機構の一部として機能する。 NetBIOS ネームサーバとデータグラム配布サーバは、 P および M ノード の名前解決およびデータグラム通信の機能を担っている。 NBNS と NBDD サーバの両方ともに、サービスを要求した P および M ノー ドから処理の一部を委任されることが可能である。 処理の割り当ては動的に行なわれ、 P および M ノードは、 NetBIOS サー バに対する処理の委任が最大限行なわれる場合に備えておくことが必須で あるため、システムは自動的に NetBIOS サーバの機能強化に追従すること になる。例えば、Internet Group Multicastiong が広範囲に用いられるよ うになった際に、新しい NBDD の実装が NetBIOS データグラムの配送に関 するすべての処理を実行するようにすることも可能である。 異なる実装間の相互接続性は、 終端ノードの実装で、NBNS および NBDD からの正しいレスポンスをすべて受け付けることを可能とすることを必要 条件とすることにより、確保される。 11.1. NetBIOS ネームサーバ (NBNS) ノード NBNS は NetBIOS 名の整合性や管理に関する責任の範囲を柔軟に設定する ことが可能なように設計されている。例えば、NBNS は、名前とアドレスの 情報を NBNS による確認なしに任意の P および M ノードが登録(や削除) を行なうことを可能とする「掲示版」的なものにとどめておくことで、完 全な責任を負わないようにすることも可能である。また NBNS は名前の管 理や確認を厳密に行なうことも可能である。 NBNS が想定する責任の範囲 は、名前の登録が行なわれる際に、NBNS が簡単な機構により通知する。 NBNS がすべての責任を負わないという場合、 NBNS が要求を行なったノー ドに対して必要な情報を返却することにより、各ノードが名前の所有者で ある可能性のあるノードに対するチャレンジを行なうことも可能である。 NetBIOS 名の管理を NBNS と P および M ノードの間で委任する機能は、 ネットワーク管理者(やベンダ)が、NBNS の単純性、セキュリティ、応答遅 延などのトレードオフを制御することを可能とする。 単一の NBNS は、DNS のように分散配置されている機構を用いて実装する ことも可能である。ただし、この RFC では、そうした場合に用いられる NetBIOS Working Group [Page 18] RFC 1001 March 1987 内部的な通信方式に関しては定義していない。 11.1.1. NBNS と DNS との関係 NBNS の設計は、 様々な箇所で DNS との連携を想定したものとなっている。 まず、 NetBIOS 名は DNS で扱うことが可能な形式でエンコードされるよ うになっている。 次に、 各 NetBIOS 名にはスコープ識別子が付加される。この識別子は DNS で利用可能な文字のみが利用可能となっており、 NetBIOS 名とはピリ オドで結合される。これにより、スコープ識別子と統合した NetBIOS 名が、 有効な DNS 名となる。 更に、NBNS の責任範囲によっては、 NBNS が単なる掲示版的に、(名前と アドレスの)情報が登録されるだけのものになることも考えられる。これは 現存する DNS システムの問い合わせサービスに類似している。 しかし、この RFC では、 NBNS に現在の DNS が提供している以上のサー ビスを提供させることを必要としている。 DNS 形式の手順とパケット形式 により、トランザクションを必要とするサービスをすべて統合させようと する試行も行なわれてきた。 DNS を NBNS として利用するために拡張が必須である機能は、以下のよう なものである: - 動的なエントリの追加 - 動的なエントリ情報の更新 - 複数のインスタンスをもつ(グループの)エントリのサポート - エントリに対する有効期限のサポートと更新メッセージの受信により 有効期限を再計算する機能のサポート - エントリに対する新しい属性 11.2. NetBIOS データグラム配布サーバ (NBDD) ノード インターネットでは、ブロードキャストやマルチキャストは未だサポート されていない。NBDD はこうした環境でも NetBIOS データグラム配布サー ビスを提供するものである。 NBDD は、あるノードがリクエストした NetBIOS データグラムの配布につ いて、完全に行なうか、部分的に行なうか、完全に拒否するかを選択でき る。終端ノードは NBDD に対して NBDD がデータグラムを特定の NetBIOS 名に対して配布したかどうかを問い合わせることができる。 NetBIOS over TCP としては、Internet Group Multicast の利用を意図し て設計されている。詳細については付録 A を参照のこと。 NetBIOS Working Group [Page 19] RFC 1001 March 1987 11.3. NBNS と NBDD ノードの関係 この RFC では NBNS と NBDD を各々別のエンティティとして定義している。 配布先の NetBIOS 名の情報がない場合、 NetBIOS データグラム配布サー バは NetBIOS スコープ内の各終端ノードに対してデータグラムを配布する 必要がある。 NBNS と NBDD ノード間で、 NetBIOS 名の情報を交換する独自のプロトコ ルを実装しても構わない。もしくは、NBNS と NBDD を同じデバイス上に実 装しても構わない。 注意: 独自の NBNS-NBDD プロトコルや NBNS と NBDD 機能を統合した実装 を行なう場合は、その旨を明示することが必須である。 11.4. NetBIOS サポートサーバと B ノードとの関係 この RFC で定義されているように、 NBNS と NBDD ノードのいずれも、 B ノードに対しては機能しない。 NetBIOS サーバは直接接続されているブロー ドキャスト領域に対するブロードキャストについても一切受信しない。ま た NetBIOS サポートサーバは、 B ノードからの登録要求や、B ノードが 保持している名前についても一切考慮しない。 NBNS と NBDD 双方について、B ノードの処理を認識して、それらを P お よび M ノードに転送するような拡張を行なうことも可能である。しかし、 そうした拡張について、本仕様では扱わない。 12. トポロジ B, P, M, NBNS, NBDD ノードは、 NetBIOS 環境を機能させていく上で、様々 な形で連携を行なうことがある。この章ではそうした連携の具体的な例を 示す。 考えられるパターンとしては、以下の 3 つのクラスが挙げられる: - Class 0: B ノードのみ - Class 1: P ノードのみ - Class 2: P および M ノードの混在 以下の記述において、任意の P ノードは M ノードに置き換えることがで きる。この置き換えの影響は、以下の各々の例の中で説明している。 12.1. ローカル環境 NetBIOS スコープは、すべてのエンティティが同一のブロードキャスト領 域内に存在している場合、ローカル環境内に設定される。 NetBIOS Working Group [Page 20] RFC 1001 March 1987 12.1.1. B ノードのみ B ノードのみによるローカルな処理は、もっとも基本的なモードである。 名前の登録と問い合わせの処理はブロードキャストを用いて行なわれる。 NetBIOS スコープはブロードキャスト領域内に限定される。この構成にお いては、 NetBIOS サポートサーバは不要である。 ====+=========+=====BROADCAST AREA=====+==========+=========+==== | | | | | | | | | | +--+--+ +--+--+ +--+--+ +--+--+ +--+--+ | B | | B | | B | | B | | B | +-----+ +-----+ +-----+ +-----+ +-----+ 12.1.2. P ノードのみ この設定は、ネットワーク管理者が NetBIOS によるブロードキャストのト ラヒックの削減を意図した際によく使われるモードである。 ====+=========+==========+=B'CAST AREA=+==========+=========+==== | | | | | | | | | | | | +--+--+ +--+--+ +--+--+ +--+--+ +--+--+ +--+--+ | P | | P | |NBNS | | P | |NBDD | | P | +-----+ +-----+ +-----+ +-----+ +-----+ +-----+ この設定により、インターネット上の場合と同様の処理が行なわれるため、 この構成をこのケースで行なうメリットは、ブロードキャストの削減のみ ということになる。 P ノードを M ノードに置換しても、その他の P ノードや M ノードの動作 には影響しない。P ノードと M ノードは互いに連携して動作する。M ノー ドはブロードキャストを利用するため、全体としてブロードキャストが増 加する。 12.1.3. B ノードと P ノードの混在環境 B および P ノードは連携して動作しない。P ノードを M ノードに変更す ることにより、B ノードと M ノードが連携して動作するようになる。 注意: B ノードと M ノードはローカルブロードキャスト領域内でのみ連携 して動作する。インターネット環境においては、B ノードと M ノー ドは連携して動作しない。 NetBIOS Working Group [Page 21] RFC 1001 March 1987 12.2. インターネット環境 12.2.1. P ノードのみ P ノードは、インターネット上の様々な箇所に分散して存在することがで きる。P ノードには、 NetBIOS 名とデータグラム機能のサポートのため、 NBNS と NBDD の両方が必要である。 NetBIOS スコープは P (および M) ノードによって用いられる NetBIOS ス コープ識別子 (ドメイン名) によって識別される。インターネットでは多 くの NetBIOS スコープが存在しうる。 +-----+ | P | +--+--+ | +-----+ | |----+ P | | | +-----+ /-----+-----\ | +-----+ | | +------+ | +-----+ | P +------+ INTERNET +--+G'WAY |-+----+ P | +-----+ | | +------+ | +-----+ /-----+-----/ | / | | +-----+ / | |----+ P | +-----+ +--+--+ | +-----+ |NBNS + |NBDD | +-----+ +--+--+ P ノードは M ノードによって置き換えることも可能である。それによる機 能の低下はない。ただし、 M ノードが存在しているブロードキャスト領域 内におけるブロードキャストが増加することになる。 NetBIOS Working Group [Page 22] RFC 1001 March 1987 12.2.2. M ノードと P ノードの混在環境 M および P ノードは混在してもよい。NetBIOS 名を保持する場合、 M ノー ドは同じブロードキャスト領域にある他の M ノードが保持している名前の 探索を、ネットワークのどこかに存在する P ノードや M ノードによって 保持されている名前の探索よりも優先して行なう。 +-----+ | P | +--+--+ | | /-----+-----\ +-----+ | | +-----+ | P +------+ INTERNET +------+NBDD | +-----+ | | +-----+ /-----+-----/ / | / | +-----+ +--+--+ |NBNS + |G'WAY| +-----+ +--+--+ | | ====+=========+==========+=B'CAST AREA=+==========+=========+==== | | | | | | | | | | | | +--+--+ +--+--+ +--+--+ +--+--+ +--+--+ +--+--+ | M | | P | | M | | P | | M | | P | +-----+ +-----+ +--+--+ +-----+ +-----+ +-----+ 注意: B および M ノードはインターネット環境において混在させるべきで はない。混在させた場合は検出できない NetBIOS 名の競合が発生し、予 期しない事態が発生する可能性がある。 13. 一般的な処理手順 後述する個別のプロトコルに依存しない部分は、一般的なエンティティ間 の処理手順である。 13.1. リクエスト/レスポンス 処理の手順 エンティティ間のほとんどの処理は、一方向からのリクエストに続いて、 反対方向へのレスポンスが行なわれる。 信頼できないトランスポート(UDPなど)上や、ブロードキャストで処理が行 なわれるといった状況では、リクエストとレスポンスの間に厳密な意味で の1対1の関係は存在しない。 NetBIOS Working Group [Page 23] RFC 1001 March 1987 ただし、受信したリクエストに対して複数のレスポンスが生成されるといっ た状態はあり得ない。レスポンスを行なうエンティティがレスポンスを保 留している場合、1つ以上の待機通知が送信されることがある。 13.1.1. リクエストの再送 UDP は信頼性のない配送の仕組みであり、パケットが消失したり、シーケ ンスに則らずに受信したり、重複したり、配送が非常に遅延したりする可 能性がある。 NetBIOS プロトコルは UDP を多用するため、こうした信頼 性の欠如を独自の仕組みにより、補っている。 各 NetBIOS のパケットには、処理に必要なすべての情報が含まれている。 単一のリクエストやレスポンスを複数の UDP パケットを使って送信するよ うなプロトコルは存在しない。単一の UDP パケットで送信できないような 大量の情報の送信が必要な場合、例えば P ノードが NetBIOS サーバから グループ名の所有者すべてを取得しようとした場合などは、TCP コネクショ ンが用いられる。また、シーケンス外の UDP パケットの配送により、 NetBIOS プロトコルに問題が発生することはない。 リクエストやレスポンスのパケットの消失に対応するため、各リクエスト 処理は、レスポンスを指定された時間内に受信しない場合に、リクエスト を再送する。 名前の競合の検出の際などに、同じレスポンスのパケットを連続して受信 することもあるが、こうした際は、プロトコル処理で、同一の NetBIOS の 情報に対して連続して受信したパケットを無視するため、重複したパケッ トは除外される。レスポンスを送信するノードの状態はリクエストに反映 されないため、レスポンス側は、リクエストパケットを受信するたびに対 応するレスポンスを送信してしまう。いずれにしても、重複したり遅延し たりしたリクエストパケットによって、処理に不具合が出ることはない。 すべてのリクエストについて、レスポンスパケットの遅延が非常に大きい 場合、代わりのパケットが再送される。再送されたリクエストパケットに 対応するレスポンスとして送信される、再送されたレスポンスパケットは、 重複したパケットと同様のパケットになる。そのため、プロトコルでは再 送されたレスポンスパケットを無視する。レスポンスの配送がリクエスト 処理が完了した後まで遅延した際には、それが成功したか否かに関わらず、 そのレスポンスパケットは無視される。 13.1.2. レスポンスのないリクエスト: 要請 リクエストによっては、対応するレスポンスが存在しないものもある。こ うしたリクエストを「要請(demand)」と呼称する。通常「要請」は絶対的 なリクエストであり、受信したノードは従うことが期待される。ただし、 要請は実施確認が行なわれないため、要請が用いられるのは、ほとんどの 場合要請パケットが消失しても致命的な問題が発生しない場合に限られる。 要請パケットは再送されない。 NetBIOS Working Group [Page 24] RFC 1001 March 1987 13.2. トランザクション エンティティ間でのやりとりの処理を「トランザクション」としてグルー プ化する。これらのトランザクションには、1つ以上のリクエスト/レスポ ンス処理が含まれる。 13.2.1. トランザクション ID 複数のトランザクションがエンティティ間で同時に実行中の場合、「トラ ンザクションID」が用いられる。 トランザクションを開始する際に、開始側でユニークな ID が設定される。 トランザクション ID は、トランザクションの各々の処理で相前後するこ ともある (訳注: The transaction id is reflected back and forth in each interaction within the transaction.)。トランザクションの相手は トランザクション ID とトランザクション相手の IP アドレスを確認して、 レスポンスをリクエストに対応付けることが必須である。対応付けるべき リクエストが見つからなかったレスポンスは破棄される。 各トランザクション毎に、新しいトランザクション ID が付与されるべき である。単純な 16 ビットのカウンタが、適切なトランザクション ID 生 成器となるであろう。トランザクションが通常のカウンタが一順する期間 を越えて存在することはまずあり得ないことであるため、ID の重複を避け るために実行中のトランザクションを検索する必要性は、おそらくないで あろう。トランザクション ID とともに IP アドレスを利用することによ り、万一利用中のトランザクション ID が再使用されてしまって障害が発 生してしまう可能性が低減される。 13.3. TCP ベースと UDP ベース このバージョンの NetBIOS over TCP プロトコルでは、多くの処理で UDP を利用している。この RFC の将来のものでは、それらの処理についても TCP コネクション上で行なうことを可能とするような拡張が行なわれるか も知れない (複数の処理がほぼ同時に行なわれた際や、 NetBIOS データグ ラムのトラヒックから、アプリケーションがコネクション指向のサービス に NetBIOS データグラムを利用していることが確認された際に、おそらく 処理効率の向上が可能になるため)。 14. NetBIOS 名の表記法 クライアントの NetBIOS インタフェース経由で表示される NetBIOS 名は、 16 バイト長であるが、NetBIOS over TCP プロトコル内ではより長い表記 が用いられている。 エンコードには 2 つのレベルがある。第 1 レベルは NetBIOS 名を DNS 名に変換する。第 2 レベルは、その DNS 名を DNS で扱えるようにする ための「圧縮された」表記に変換する。 あるパケットを除き、第 2 レベルの表記は NetBIOS over TCP のパケット フォーマットで使われる唯一の NetBIOS の表記法である。例外は、 NODE_STATUS_RESPONSE パケットの RDATA フィールドである。 NetBIOS Working Group [Page 25] RFC 1001 March 1987 14.1. 第 1 レベルのエンコーディング 第 1 レベルの表記法は、2 つのパートからなる: - NetBIOS 名 - NetBIOS スコープ識別子 16 バイトの NetBIOS 名は、 可逆な 7 ビット ASCII 文字のみを用いたエ ンコーディングを用いた 32 バイト長のフィールドに変換される。NetBIOS 名に含まれる、各 half octet は、 32 バイトのフィールドの 1 バイトを 構成するようにエンコードされる。最初の half octet が最初のバイトに エンコードされ、 2 番目の half octet が 2 番目のバイトに変更される。 NetBIOS 名の各 half octet (4 ビット) を各々右詰めし、残りの部分をゼ ロクリアした 8 ビットのバイナリ値として扱う。この値に ASCII 文字の 「A」 (16 進数で 41) を加算する。この結果生成された 8 ビット値を適 切な位置に格納する。以下にこの処理を図示する: 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ |a b c d|w x y z| 元々のバイト +-+-+-+-+-+-+-+-+ | | +--------+ +--------+ | | 4ビットに分割 v v 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ |0 0 0 0 a b c d| |0 0 0 0 w x y z| +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ | | + + 'A' を追加 | | 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ |0 1 0 0 0 0 0 1| |0 1 0 0 0 0 0 1| +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ このエンコーディングの結果、 NetBIOS 名は、 ASCII 大文字 (A, B, C, .... N. O. P) からなる 32 バイトの文字列に変換されることになる。 NetBIOS スコープ識別子は、ドメイン名として適切な書式(先頭のドットは 付けない)になっている。 ASCII の「.」 (16 進数で 2E) とスコープ識別子が、 NetBIOS 名のエン コードされたものに付加される。結果として生成された文字列は、ドメイ ン名として適切な形式になる。 NetBIOS Working Group [Page 26] RFC 1001 March 1987 例えば、「SCOPE.ID.COM」という NetBIOS スコープ内にある「The NetBIOS name」という NetBIOS 名を、第 1 レベルの ASCII 文字列にする と、以下のようになる: FEGHGFCAEOGFHEECEJEPFDCAHEGBGNGF.SCOPE.ID.COM 14.2. 第 2 レベルのエンコーディング 第 1 レベルのエンコーディングは、第 2 レベルのエンコーディングに置 換することが必須である。これは、 RFC 883[12] の 31 ページにある 「Domain name representation and compression」で定義されている規定 にしたがって行なわれる。詳細な仕様[1] の「Name Formats」という章も 参照すること。 15. NetBIOS ネームサービス 名前が使えるようにするためには、名前はノードによって登録されること が必要である。一度登録に成功すると、その名前は他のノードによる不整 合を引き起こす登録に対して保護される必要がある。NetBIOS セッション の確立、もしくは NetBIOS データグラムの送信前に、名前の所有者は、名 前を保持(locate)しておく必要がある。 NetBIOS ネームサービスはノードが NetBIOS 名の登録、保護、保持を行な う一連の手順の集合体である。 ネームサービスの手順は、終端ノードのタイプが B, P, M いずれかによっ て異なる。 15.1. NetBIOS ネームサービスの概要 15.1.1. 名前の登録 (CLAIM) 各 NetBIOS のノードは 1 つ以上の名前を所有している。名前は登録(name claim)の手順を経て、動的に登録される。 各ノードは静的なユニーク名を持っている。この名前も、他の名前と同様 に、どの終端ノードのタイプにおいても明示的に登録される必要がある。 名前はユニーク名(排他的)か、グループ名(非排他的)のいずれかである。 ユニーク名は単一のノードのみによって所有される。グループ名は、幾つ のノードによって所有されてもよい。名前がどのノードからも所有されな くなると、その名前は存在しなくなる。本質的に名前自身には、機能を示 すような意味はない。それらは登録時に結びつけられるものである。 各ノードは登録した名前の各々についてステータス情報を維持する。ステー タス情報には以下のようなものがある: - 名前がユニーク名か、グループ名か - 名前が「競合状態(in conflict)」にあるか - 名前が削除途中の状態にあるか NetBIOS Working Group [Page 27] RFC 1001 March 1987 B ノードは、名前の登録をブロードキャストのリクエストで行ない、すで に名前を所有しているノードからの保護の要請を行なう。 P ノードは、名前の登録を NBNS に対して行なう。 M ノードは、名前の登録を、まず B ノードのようにブロードキャストで行 ない、保護の要請がない場合は、ついで P ノードと同じ方式で引続き処理 を行なう。言い替えると、ブロードキャストの処理で登録が中止されるこ ともあるが、それだけでは登録が完了したとはみなされないということで ある。 15.1.2. 名前の問い合わせ (DISCOVERY) 名前の問い合わせ(「名前解決」、「名前の発見」と呼ばれることもある) は、ある NetBIOS 名に対応する IP アドレスを発見する手順である。名前 の問い合わせは、以下の処理の際に必要である: セッション確立時、呼出元と呼出先の名前が特定されていることが必須で ある。呼出元の名前は CALL を行なったノード上に存在していることが必 須であり、呼出先の名前は、LISTEN を行なっているノード上に存在してい ることが必須である。いずれもユニーク名、グループ名どちらでもよい。 ユニキャストのデータグラムが送信された場合、送信元と送信先の名前が 特定される必要がある。送信先の名前がグループ名の場合、データグラム はグループのメンバすべてに対して送信される。 終端タイプによって、名前解決の方法も異なるが、用いられるパケットの フォーマットは同一である: - B ノードはブロードキャストにより名前の情報を取得しようとする。 - P ノードは NBNS に問い合わせる。 - M ノードはブロードキャストを行なうが、それで求めている情報が得 られなかった場合、 NBNS に対して問い合わせを送信する。 15.1.3. 名前の解放 NetBIOS 名は、終端ノードによって明示的に、もしくは暗黙の内に解放さ れることがある。暗黙の解放は、通常、終端ノードが異常になったり、電 源がオフになったりした際に発生する。以下で記述する仕組みのほとんど は、暗黙の名前の解放を検出する為に存在している。 15.1.3.1. 明示的な解放 B ノードは、ブロードキャストで通知することで明示的な解放を行なう。 P ノードは NBNS に対して通知を送信する。 M ノードはブロードキャストと NBNS への通知の両方を行なう。 NetBIOS Working Group [Page 28] RFC 1001 March 1987 15.1.3.2. 名前の有効期限と更新 NBNS に保持されている名前は、名前の登録時に有効期限が設定される。 NBNS は、有効期限を過ぎる前に終端ノードから名前の更新メッセージが送 信されてこない場合、暗黙の内に名前の解放が行なわれたと判断する。 注意: 実装を行なう際には、データベースの更新頻度と更新機構がもたら すインターネットに対するオーバーヘッドのトレードオフを熟慮す ること。有効期限は適切に調整する必要がある。 グループ名の場合も、各終端ノードは更新メッセージを送信する必要があ る。更新メッセージを送信しなかった終端ノードはその名前を暗黙の内に 解放したものとみなされ、そのグループから除外される。 有効期限は名前登録時の簡単なやりとりによって設定される。名前登録の 要求において、終端ノードは有効期限の要求、もしくは無制限の有効期限 の要求を行なう。 NBNS は、名前登録のレスポンス中に、有効期限の値を 設定して返却する。 NBNS は、常に有効期限無制限のレスポンスを返して も構わない。終端ノードが無制限の有効期限を要求した場合にも、 NBNS は有限の有効期限を返却するかも知れない。終端ノードが有限の有効期限 を要求した場合は、 NBNS が要求されたものと同じか、より長い期限を返 却する場合もある。 この更新に関するネゴシエーションにより、 NBNS は更新機能を有効にし たり、無効にしたりすることが可能になる。終端ノードは最低限の更新間 隔を設定しても構わない。 NBNS は、完全に信頼すべき存在と考えられているため、更新を無効にする ことも可能になっている。 15.1.3.3. 名前の確認 ノードが暗黙の内に要求していた名前を解放したかどうかを確認するため に、あるノードが現在名前を所有しているかどうかを確認することが必要 である。ノードが名前を保護した場合、そのノードは名前を所有し続ける ことができる。それ以外の場合、そのノードは名前を解放したものとして 扱われる。 名前の確認は、 P ノードや M ノードの場合、 NBNS によって行なわれる。 確認は、終端ノードが B, P, M いずれの場合もユニキャストで行なわれる。 15.1.3.4. グループ名の消滅 NetBIOS のグループは、多くのメンバーが含まれる場合がある。確認のた びにすべてのメンバーが応答するのは非常に負荷が高くなる場合がある。 遅延が大きくなるのを防ぐため、 NBNS 経由で名前の登録が行なわれる場 NetBIOS Working Group [Page 29] RFC 1001 March 1987 場合は、楽観的な確認が行なわれるようになっている。すなわち、常にい ずれかのノードがグループ名を保護したと仮定される。結果として、 NBNS は、すでに登録されているグループ名と同じ名前のユニーク名の登録要求 を直ちに拒否することになる。グループ名が存在している時に、NBNS が (名前登録要求のレスポンスで) IP アドレスを返却することはありえない。 NBNS は、最後に残ったメンバーから定期的な更新メッセージが送信されて こなかったか、明示的に名前が解放された場合に、グループ名が解放され たとみなす。 15.1.3.5. 名前の競合 名前の競合は、あるユニーク名が NetBIOS ネットワーク上の複数のノード で登録された場合に発生する。B, M および NBNS のノードが、名前の競合 を検出しうる。B および M ノードにおける検出の仕組みは名前の問い合わ せの際にのみ有効である。 NBNS は自身の名前データベースの整合性を確 認することにより、いつでも名前の競合を検出することが可能である。 B および M ノードは、ブロードキャストの名前問い合わせ要求の応答とし て受け取ったレスポンスを確認することで、競合を検出することが可能で ある。最初のレスポンスは正当なものとして扱われれる。その後レスポン スがあると、整合性が保たれておらず、競合が発生したと認識される。 その後のレスポンスにより、正当なレスポンスとの間の整合性が保たれて いないと判断されるのは、以下の場合である: その後のレスポンスにおいて、名前問い合わせ要求のトランザクショ ン ID が同一である。 かつ その後のレスポンスは正当なレスポンスの複製ではない。 および: 正当なレスポンスは、ユニーク名/グループ名のうち、ユニーク 名である。 もしくは その後のレスポンスは、ユニーク名/グループ名のうち、ユニー ク名である。 B および M ノードがレスポンスを待つ期間は、 競合タイマである CONFLICT_TIME の値によって制限される。このタイマの頻度や期間はあま り重要ではない: NetBIOS システムは、常に名前の競合が発生していても、 処理を続けることが可能である。 競合状態は、問題の名前を所有しているノードに対して、 NAME CONFLICT DEMAND を送信することにより、通知される。正当なレスポンスを送信した ノードに対しては、何も送信されない。 NAME CONFLICT DEMAND を受信した終端ノードは、「ローカルな名前テーブ ル」を更新して、その名前を競合状態にすることを要求される (各ノード の「ローカルな名前テーブル」には、そのノードによって登録が成功した NetBIOS Working Group [Page 30] RFC 1001 March 1987 名前が含まれている)。 名前の競合メッセージを受信したノードのみが名前に競合マークを設定す ることに注意。 論理的には、マークの付けられた名前はそのノードが所有していない。こ れは、このノードが (名前の登録要求時に) その名前を保護することがで きず、その名前の名前問い合わせ要求に対して応答することができず、ま たその名前に対する更新メッセージを送信することもできないことを意味 する。さらに、その名前をセッションの確立や、データグラムの送受信に 用いることもできなくなる。すでに存在しているセッションに対しては、 名前が競合状態になった時点での影響はない。 マークされた名前に対する唯一の正当なユーザからの操作は、 DELETE NAME である。それ以外の NetBIOS の操作は、「NAME CONFLICT」のエラー コードが直ちに返却される。 15.1.4. アダプタステータス 終端ノードおよび NBNS は、その他の終端ノードに対してそのノードの NetBIOS ステータス情報を問い合わせることがある。このステータス情報 は様々な情報からなっているが、その中に、そのノードが所有していると 考えている名前の一覧が含まれている。返却されたステータスは、要求側 の名前に含まれている NetBIOS スコープ識別子と同じ識別子をもった名 前のみが含まれるようにフィルタが行なわれている。 ノードのステータス情報が要求された場合、要求側は、 NetBIOS 名によっ て要求対象のノードから識別される。該当する名前に対する IP アドレス を取得する為には、名前問い合わせの処理が必要となる。ローカルに キャッシュされた名前の情報が名前問い合わせの処理の代わりに用いられ ることもある。要求を行なうノードは NODE STATUS REQUEST を送信する。 要求されたノードは NODE STATUS RESPONSE を送信する。これには様々な 統計情報とともに、ローカルな名前テーブルの内容が含まれる。 返却されるステータスのサイズは、 UDP パケットのサイズの上限によって 制約される。ただし、通常の NODE STATUS RESPONSE パケットについて、 このサイズは充分である。 15.1.5. 終端ノードの NBNS 処理 終端ノードの NBNS 関連の処理には、特定のトランザクション方式に依存 しない共通的な特徴が存在する。 15.1.5.1. UDP, TCP および切り詰め(truncation) 終端ノードと NBNS 間で行なわれるすべてのトランザクションは、トラン スポートとして UDP と TCP のいずれを用いてもよい。 NBNS は、 UDP の リクエストを受信した場合、 UDP で応答を行なう。情報の量が UDP パケッ トで格納可能な量を超過した場合、レスポンスには、「truncation フラグ」 が付与される。この場合、終端ノードは NBNS に対して TCP コネクション NetBIOS Working Group [Page 31] RFC 1001 March 1987 を確立し、再度要求を行なうことで、切り詰められていない完全なレスポ ンスを取得する。 15.1.5.2. NBNS WACK ネームサービスの要求が処理中の場合、 NBNS は、クライアントの終端ノー ドに対して NBNS は機能しており、リクエストの処理中であることを通知 するために WAIT FOR ACKNOWLEDGEMENT RESPONSE (WACK) を返却すること がある。 15.1.5.3. NBNS 転送(REDIRECTION) NBNS は DNS と同様の処理を行なうために、クライアントを別の NBNS に 転送してもよい。 15.1.6. セキュアな NBNS と非セキュアな NBNS NBNS の実装には、二通りの方法が考えられる。 NBNS が、名前の一貫性を 保つために、名前の保持や登録を行なう場合、これを「セキュアな」 NBNS と呼ぶ。一方 NBNS が名前の登録を受け付ける「掲示版」的な実装をされ ており、名前の一貫性維持の責任が終端ノードに委ねられている場合、こ れを「非セキュアな」 NBNS と呼ぶ。 15.1.7. NBNS データベースの一貫性 NetBIOS スコープが適切に設定されている場合であっても、 NBNS と関連 する終端ノードの間で、名前の登録状況に関する整合性を失われることが ある。 これは、 NBNS がデータベース全体、もしくは一部を失うことなどにより 発生する。 また、よくある状況として、 P および M ノードが電源断され (名前の登 録を行なったことも忘れられ)、その後電源を入れられることが考えられる。 このようにして、エラーが発生したり、動作が不安定になることがある。 NetBIOS over TCP プロトコルにおける、こうした問題の影響を最小限にと どめるため、様々な解決策が行なわれてきた。 1. NBNS (もしくは他のノード) は、(NAME QUERY REQUEST を用いて) 終端ノードに対する「チャレンジ」を行ない、本当にその名前を 所有しているかどうかを確認するようにする。 こうしたチャレンジは任意のタイミングで発生する。各終端ノー ドは即座に応答を返却できるようにしておくことが必須である。 レスポンスの返却が行なわれなかった場合、 NBNS は、終端ノー ドが問い合わせ対象の名前を解放したものとして扱う (UDP が下 NetBIOS Working Group [Page 32] RFC 1001 March 1987 位トランスポートとして利用されている場合、チャレンジや関連 するリクエストは、レスポンスがない場合に、何回か再送を行な うことが必須である) 2. NBNS (もしくは他のノード) は (NODE STATUS REQUEST を用いて)、 終端ノードに対して登録している名前の一覧を返却するように要 求してもよい。 これは任意のタイミングで発生する。各終端ノードは即座に応答 を返却できるようにしておくことが必須である。 レスポンスの返却が行なわれなかった場合、 NBNS は、終端ノー ドに問題が発生し、登録を行なったすべての名前が解放されたも のとして扱ってもよい(ただし、必須ではない)。(チャレンジの場 合と同様、UDP がトランスポートとして利用されている場合、リ クエストは、レスポンスがない場合に、再送を行なうことが必須 である) 3. NBNS は、P もしくは M ノードに対して、 NAME CONFLICT DEMAND か NAME RELEASE REQUEST を送信することにより、名前の登録を 停止させることが可能である。 受信した終端ノードは、該当の名前を使ったセッションについて、 すでに確立されているものについては使い続けることができるが、 それ以外は、該当の名前の利用を停止することが必須である。 NBNS が名前を競合状態に設定した場合、一度解放を行なってから、 再度登録を行なうことによってのみ、該当の名前を再度登録する ことが可能である。NBNS が名前の解放を要求した場合、そのノー ドは名前の解放を行なわずに、名前の再登録を行なっても良い。 4. NBNS は、登録する名前に対して「有効期限」の情報を必ず付加す るようにしてもよい。登録を行なったノードは名前の登録処理を 行なう際に、この値について通知される。 単純な NBNS や信頼されている NBNS は、無期限の有効期限を付 加してもよい。 5. 終端ノードが無期限の有効期限を持つ名前を保持している場合、 そのノードは定期的に NBNS に対してステータス報告を送信する ことが必須である。各々の名前は、 NAME REFRESH REQUEST パケッ トを使うことで、報告される。 これらのステータス報告は NBNS と報告を行なったノードの双方 で、タイマーを初期化する。ただし、初期化されるタイマーは、 ステータス報告中に存在している名前に対するもののみである。 それ以外の名前に対するタイマーは関係ない。 NBNS は、名前の有効期限の何倍かの期間更新されなかった名前に ついては、解放されたとみなしてもよい。 ただし、 NBNS は、名前を削除する前に、報告を行なわないノー NetBIOS Working Group [Page 33] RFC 1001 March 1987 ドに対してチャレンジを発行するか、名前の一覧の返却を要求す ることが望ましい。レスポンスがないか、レスポンス中に該当す る名前がない場合、 NBNS は名前の削除を行なうことになる。 6. 報告が行なわれなかった場合、 NBNS は終端ノードは異常になっ たと判断する。同様に、受信した情報が NBNS の想定していたも のと大きく異なっている場合にも、 NBNS は終端ノードが再起動 したものと判断しても構わない。 NBNS はチャレンジや名前の一覧の要求を行なうことで、現状の把 握を行なうことが可能である。 7. 非常に厳密な NBNS では、 (NAME QUERY REQUEST や NODE STATUS REQUEST パケットを送信することで) ノードに対してポーリング を行ない、名前の状態が NBNS に登録されたものと同一であるこ とを確認しても構わない。 注意: こうしたポーリングの実装を行なう場合も、あまり頻繁に 行なうべきではなく、 何らかの理由で、 NBNS が情報に不整合が 発生しているのではないかと判断している場合にのみ、有効にす べきである。 8. P および M ノードは、セッションの確立時に名前の情報が不正に なっていることを検知することも可能である。 不正な情報が検知された場合、 NBNS は、エラーを検知した終端 ノードからの NAME RELEASE REQUEST パケットによって、それを 通知される。 15.1.8. 名前のキャッシュ 終端ノードは、 NetBIOS 名と IP アドレスとを対応させる、ローカルな キャッシュを保持してもよい。 すべてのキャッシュエントリは、一定期間後にフラッシュされるべきである。 また、ある IP アドレスのノードにトラブルが発生した可能性があるとい う何らかの情報を受信した場合、その IP アドレスに関連するキャッシュ 情報はフラッシュすることが強く求められる。例えば、 NAME CONFLICT DEMAND があるノードに送信された場合、そのノードに関してキャッシュさ れていたすべての情報は、送信を行なったノードの中のエントリからフラッ シュされるべきである。 15.2. 名前登録のトランザクション 15.2.1. B ノードによる名前登録 B ノードが行なう名前登録のトランザクションは、ブロードキャスト領域 内へのブロードキャストによって行なわれる。 NAME REGISTRATION NetBIOS Working Group [Page 34] RFC 1001 March 1987 REQUEST は、領域内の B および M ノードが受信する。各ノードは登録を 要求されている名前と、自分が所有するものとの不整合が発生していない ことを確認する。不整合が発生した場合、 NEGATIVE NAME REGISTRATION RESPONSE が要求を行なったノードにユニキャストで返却される。要求した ノードは、 NEGATIVE NAME REGISTRATION RESPONSE を、CONFLICT_TIME で 指定される名前登録のタイムアウト中に受信しなかった場合にのみ、その 名前の所有者となる (もしくはグループのメンバーとなる) 。 (このタイ マ値の詳細な仕様については、「定義された定数と変数」を参照のこと) B ノードは NAME OVERWRITE DEMAND をブロードキャストすることにより、 ある名前の所有者となったことを通知する。 B ノードの登録手順 <-----NAME NOT ON NETWORK------> <----NAME ALREADY EXISTS----> 要求ノード NODE 要求ノード HOLDING NAME (BROADCAST) REGISTER (BROADCAST) REGISTER -------------------> <------------------- REGISTER REGISTER -------------------> <------------------- REGISTER NEGATIVE RESPONSE -------------------> ------------------------------> OVERWRITE -------------------> (ノードは名前を所有しない) (ノードは名前を所有する) NAME REGISTRATION REQUEST が BCAST_REQ_RETRY_TIMEOUT 内にレスポンス を受信できなかった場合、他と同様に送信を繰り返すことが必須である。 リクエストは、BCAST_REQ_RETRY_COUNT で指定された回数だけ繰り返される。 15.2.2. P ノードによる名前登録 名前登録は、NBNS からみて新規の名前登録かどうかによって、幾つかの手 順に従い行なわれる。 NBNS からみて既知の名前の場合、以前の所有者に 対してチャレンジが送信されることがある。 15.2.2.1. 新規の名前、新規のグループメンバ 以下の図は、終端ノードが NBNS からみて新規の名前を登録しようとした 際に行なわれる処理の手順になる (この図では WACK, NBNS リダイレクショ ン, リクエストの再送は省略している)。 登録しようとしている名前がグループ名であり、グループがすでに存在し ている場合にも、同様の処理が行なわれる。 NBNS は登録者をグループメ NetBIOS Working Group [Page 35] RFC 1001 March 1987 ンバーに追加する。 P ノードの登録処理 (サーバは、登録される名前の情報を保持していない) P ノード NBNS REGISTER ---------------------------------> POSITIVE RESPONSE <--------------------------------- この処理は、単純である。終端ノードは NAME REGISTRATION REQUEST を 送信し、 NBNS は POSITIVE NAME REGISTRATION RESPONSE で応答する。 15.2.2.2. 既存の名前で、所有者も動作している場合 以下の図は、ユニーク名を登録する際に、 NBNS が既存の所有者を認識し ており、既存の所有者は動作している場合の処理を示したものである。 この図は、右と左とにわかれている。左側は、非セキュアな NBNS が行な う処理になる。セキュアな NBNS が行なう処理は、右側のものになる。 P ノードの登録処理 (サーバが以前の所有者の情報を保持しており、所有者が動作している) <------非セキュアな場合--------> <--------セキュアな場合-------> REQ. NODE NBNS NODE NBNS REQ.NODE HOLDING NAME REGISTER REGISTER -------------------> <------------------- QUERY END-NODE CHALLENGE <------------ <------------------- QUERY <------------ QUERY -----------------------------> POSITIVE RESP QUERY ------------> -----------------------------> NEGATIVE RESPONSE -----------------> POSITIVE RESPONSE <---------------------------- NetBIOS Working Group [Page 36] RFC 1001 March 1987 非セキュアな NBNS は NAME REGISTRATION REQUEST に対して、 END-NODE CHALLENGE REGISTRATION RESPONSE で応答する。このレスポンスにより、 終端ノードは、レスポンスで示されたノードに対してチャレンジトランザ クションを発行することを求められる。この場合、既存のノードはチャレ ンジに対して名前を保護するため、登録しようとした終端ノードは NBNS に対してそれ以上の処理を行なうことなく、登録の試行を中止する。 セキュアな NBNS は NBNS 自身が既存の名前の所有者に対してチャレンジ を行なうまで、 NAME REGISTRATION REQUEST に対する応答を保留する。こ の場合、 NBNS により、その名前が保護されているかどうかが確認され、 NBNS から NEGATIVE NAME REGISTRATION RESPONSE が登録しようとしたノー ドに対して返却される。 セキュアな NBNS が応答を返却するまでに時間がかかる可能性があるため、 NBNS から登録しようとしたノードに対して WACK が送信されることもある。 この図には示されていないが、非セキュアな NBNS も、すでに存在するグ ループ名と同じユニーク名を登録しようとしたノードに対しては NEGATIVE NANE REGISTRATION RESPONSE を送信する。セキュアな NBNS はグループの メンバに対して、動作中のメンバが存在しているかどうかの確認を行なう ことも可能である。これはネットワークに多大な負荷を掛けることがある。 グループ名は名前の更新の機構により、自然消滅するようにすることを推 奨する。 15.2.2.3. 既存の名前で、所有者が動作していない場合 以下の図は、ユニーク名を登録する際に、 NBNS が既存の所有者を認識し ているが、既存の所有者は動作していない場合の処理を示したものである。 非セキュアな NBNS は NAME REGISTRATION REQUEST に対して、 END-NODE CHALLENGE REGISTRATION RESPONSE で応答する。このレスポンスにより、 終端ノードは、レスポンスで示されたノードに対してチャレンジトランザ クション発行することを求められる。この場合、これまで名前を所有して きたノードはチャレンジに対して名前の保護を行なわないため、登録しよ うとした終端ノードは NBNS に対して NAME OVERWRITE REQUEST を送信す る。 NBNS はデータベース中にある以前の名前の情報を上書き要求のもの に置き換える。 セキュアな NBNS は NBNS 自身が既存の名前の所有者に対してチャレンジ を行なうまで、 NAME REGISTRATION REQUEST に対する応答を保留する。こ の場合、 NBNS により、その名前が保護されていないことが確認され、登 録しようとしたノードには、 POSITIVE NAME REGISTRATION RESPONSE が返 却される。 NetBIOS Working Group [Page 37] RFC 1001 March 1987 P ノードの登録処理 (サーバが以前の所有者の情報を保持しており、所有者が動作していない) <------非セキュアな場合--------> <--------セキュアな場合-------> REQ. NODE NBNS NODE NBNS REQ.NODE HOLDING NAME REGISTER REGISTER -------------------> <------------------- QUERY END-NODE CHALLENGE <------------ <------------------- QUERY <------------ NAME QUERY REQUEST POSITIVE RESPONSE ----------------------------> ------------------> QUERY ----------------------------> OVERWRITE -------------------> POSITIVE RESPONSE <------------------ セキュアな NBNS が応答を返却するまでに時間がかかる可能性があるため、 NBNS から登録しようとしたノードに対して WACK が送信されることもある。 セキュアな NBNS が NAME OVERWRITE REQUEST を受信した場合は、直ちに、 NEGATIVE NAME REGISTRATION RESPONSE を送信する。 15.2.3. M ノードによる名前登録 M ノードは、まず名前の登録処理を B ノードのように行なう。すなわち NAME REGISTRATION REQUEST をブロードキャストして NEGATIVE NAME REGISTRATION RESPONSE が返却されないことを確認する。NEGATIVE NAME REGISTRATION RESPONSE を受信した場合、名前の登録は失敗し、 M ノード は名前の登録処理を中止する。 ただし、 M ノードが NEGATIVE NAME REGISTRATION RESPONSE を受信しな かった場合、 M ノードは P ノードのようにして名前登録処理を継続する ことが必須である。 両方の名前の登録処理が成功した場合のみ、 M ノードは名前の登録を行な うことになる。 以下の図に、 M ノードの名前登録の様子を示す: NetBIOS Working Group [Page 38] RFC 1001 March 1987 M ノードの登録処理 <---NAME NOT IN BROADCAST AREA--> <--NAME IS IN BROADCAST AREA--> REQ. NODE NODE REQ.NODE HOLDING NAME (BROADCAST) REGISTER (BROADCAST) REGISTER -------------------> <------------------- REGISTER REGISTER -------------------> <------------------- REGISTER NEGATIVE RESPONSE -------------------> -------------------------------> ! (NODE DOES NOT HAVE THE NAME) INITIATE ! A P-NODE ! REGISTRATION ! V 15.3. 名前問い合わせのトランザクション 名前問い合わせのトランザクションは、ある NetBIOS 名に対応する IP ア ドレスやその他の属性を取得するために、終端ノードによって行なわれる。 15.3.1. B ノードによる問い合わせ 以下の図に、 B ノードが名前の所有者を問い合わせる方式を示す。 図の左半分は、名前の所有者がいなかった場合の動作を示している。この 場合、ブロードキャストの NAME QUERY REQUEST に対するレスポンスは、 どこからも返却されない。 右半分では、ブロードキャストのリクエストに対する応答として、名前の 所有者から POSITIVE NAME QUERY RESPONSE がユニキャストで返却されて いる。名前の所有者は、 NAME QUERY REQUEST を受信するたび、何らかの レスポンスを返却する。各々の所有者がこの動作をするため、要求を送信 したノードは多くのノードから重複したレスポンスを受信することもある。 NetBIOS Working Group [Page 39] RFC 1001 March 1987 B ノードの問い合わせ処理 <------NAME NOT ON NETWORK------> <---NAME PRESENT ON NETWORK--> REQ. NODE NODE REQ.NODE HOLDING NAME (BROADCAST) QUERY (BROADCAST) QUERY ----------------------> <--------------------- NAME QUERY REQUEST NAME QUERY REQUEST ----------------------> <--------------------- QUERY POSITIVE RESPONSE ----------------------> ------------------------------> 名前の問い合わせは、必須ではないものの、一般的に NetBIOS セッション の確立や、 NetBIOS データグラムの送信の前に行なわれる。ただし、名前 の問い合わせは他の目的で行なわれることもある。 B ノードは、今後の利用のため(セッションの確立など)、応答を収集して 保存することで、グループのメンバー一覧の構築を行なっても構わない。 15.3.2. P ノードによる問い合わせ NBNS は、 P ノードからの問い合わせに対して、IP アドレスと各々の名前 の所有者に関する情報のリストを返却する。所有者が複数の場合 (名前の グループ名の場合)、 NBNS は、 UDP パケットに格納できる範囲でレスポ ンス中に所有者に関する情報を格納する。所有者に関する情報が格納しき れなかった場合、 truncation フラグが有効になる。問い合わせを TCP で 行なうことにより、すべての情報を取得することが可能である。 NBNS は返却するリストの順番に関して考慮する必要はない。 以下の図では、 NBNS が名前に関する情報を保持していなかった場合の様 子を示す。 P ノードの問い合わせ処理 (サーバは、登録される名前の情報を保持していない) P-NODE NBNS NAME QUERY REQUEST ---------------------------------> NEGATIVE RESPONSE <--------------------------------- NetBIOS Working Group [Page 40] RFC 1001 March 1987 次の図では、 NBNS が名前に関する情報を保持していた場合に NBNS と終 端ノード間で行なわれる処理について示している。さらに、この図では、 終端ノードが一定時間内にレスポンスを得られなかった場合に行なわれる リクエストの再送についても示している。また、 NBNS により(一時的な中 間のレスポンスとして)、終端ノードに対して送信される WACK についても 示している: P ノードの問い合わせ処理 (サーバは、登録される名前の情報を保持している) P-NODE NBNS NAME QUERY REQUEST /----------------------------------------> / ! (OPTIONAL) WACK ! <- - - - - - - - - - - - - - - - - - - - ! ! !timer ! ! ! (optional timer restart) ! ! \ V QUERY \---------------------------------------> . . . QUERY /----------------------------------------> / ! (OPTIONAL) WACK ! <- - - - - - - - - - - - - - - - - - - - ! ! !timer ! ! ! (optional timer restart) ! ! \ V QUERY \---------------------------------------> . . POSITIVE RESPONSE <----------------------------------------- 以下の図は、 NBNS リダイレクションについて示している。 NAME QUERY REQUEST を受信すると、 NBNS はクライアントを別の NBNS にリダイレク トする。クライアントは、その新しい NBNS に対して再度リクエストを送 信して、レスポンスを待つ。図ではレスポンスが POSITIVE NAME QUERY RESPONSE の場合について示しているが、実際には適切な NBNS レスポンス のいずれもが返却されうる。 NetBIOS Working Group [Page 41] RFC 1001 March 1987 NBNS リダイレクション P-NODE NBNS NAME QUERY REQUEST ---------------------------------> REDIRECT NAME QUERY RESPONSE <--------------------------------- (指定された、新 しい NBNS のア ドレスを使って の処理が開始さ れる) 5 NEW P-NODE NBNS NAME QUERY REQUEST ---------------------------------> POSITIVE NAME QUERY RESPONSE <--------------------------------- 次の図では、 P ノードと M ノードが不正な情報を保持している NBNS に 対して、それを通知する処理について示している。この処理は、 DATAGRAM ERROR パケットを受信するか、セッションを開設しようとして、以前に NBNS に対して名前問い合わせのトランザクションを行なって取得していた IP アドレスに対応する NetBIOS 名が通信先に存在しないということが確 認された際に行なわれることがある。 この場合 (セキュアな) NBNS は、 その情報が不正になっているかどうかを確認するための問い合わせを送出 する。 NBNS は確認した結果に基づき、 POSITIVE もしくは NEGATIVE NAME RELEASE RESPONSE を送信してトランザクションを終了させる。 NBNS 上の情報が正しい場合 P ノード NBNS NAME RELEASE REQUEST ---------------------------------> QUERY ----------------> QUERY ----------------> (NAME TAKEN OFF THE DATABASE IF NBNS FINDS IT TO BE INCORRECT) POSITIVE/NEGATIVE RESPONSE <--------------------------------- NetBIOS Working Group [Page 42] RFC 1001 March 1987 15.3.3. M ノードによる問い合わせ M ノードの名前問い合わせは、 B ノードの形式に準じる。適切なレスポン スがなかった場合、 M ノードは P ノード形式の問い合わせを行なうこと で、処理を継続する。これを図示したものを以下に示す: M ノードの問い合わせ処理 <---NAME NOT ON BROADCAST AREA--> <--NAME IS ON BROADCAST AREA-> REQ. NODE NODE REQ.NODE HOLDING NAME (BROADCAST) QUERY (BROADCAST) QUERY ---------------------> <---------------------- NAME QUERY REQUEST NAME QUERY REQUEST ---------------------> <---------------------- QUERY POSITIVE RESPONSE ---------------------> -------------------------------> ! INITIATE ! A P-NODE ! DISCOVERY ! PROCESS ! V 15.3.4. グループのメンバ一覧の取得 グループのメンバの一覧は、 NBNS に対して NAME QUERY REQUEST を送信 することにより取得することができる。 NBNS は POSITIVE NAME QUERY REQUEST か NEGATIVE NAME QUERY RESPONSE で応答する。否定応答の場合、 処理は完了し、グループに所属するメンバがいないことが示される。 肯定応答があり、 truncation ビットが設定されていない場合、応答には グループメンバの一覧が含まれている。 truncation ビットが設定されて いた場合、処理が再度繰り返されるが、今度は UDP ベースではなく、 TCP ベースで処理が行なわれる。 NetBIOS Working Group [Page 43] RFC 1001 March 1987 15.4. 名前解放の処理(トランザクション) 15.4.1. B ノードによる名前解放 NAME RELEASE DEMAND には、以下の情報が含まれる: - NetBIOS 名 - NetBIOS 名のスコープ - 名前のタイプ: ユニーク、グループ - 解放を行なうノードの IP アドレス - トランザクション ID REQUESTING OTHER B-NODE B-NODES NAME RELEASE DEMAND ----------------------------------> 15.4.2. P ノードによる名前解放 NAME RELEASE REQUEST には、以下の情報が含まれる: - NetBIOS 名 - NetBIOS 名のスコープ - 名前のタイプ: ユニーク、グループ - 解放を行なうノードの IP アドレス - トランザクション ID NAME RELEASE RESPONSE には、以下の情報が含まれる: - NetBIOS 名 - NetBIOS 名のスコープ - 名前のタイプ: ユニーク、グループ - 解放を行なうノードの IP アドレス - トランザクション ID - 結果: - Yes: 名前は解放された - No: 名前は解放されなかった、理由コードが含まれる REQUESTING P-NODE NBNS NAME RELEASE REQUEST ----------------------------------> NAME RELEASE RESPONSE <--------------------------------- 15.4.3. M ノードによる名前解放 M ノードの名前解放は、 P ノードと B ノードの名前解放の組合せで行な われる。M ノードは、まず P ノードの解放手順を実行する。これが失敗 NetBIOS Working Group [Page 44] RFC 1001 March 1987 すると、解放の手続きは中断され、失敗となる。P ノードの手順が成功し た場合、続いて M ノードは B ノードの手順に従い、NAME RELEASE DEMAND をブロードキャスト領域にブロードキャストする。 注意: M ノードは、まず B ノード形式の処理を行なってから、 P ノード 形式の処理を行なう場合が多いが、この場合は P ノード形式の処理 が先に行なわれる。 以下の図では、 M ノードの名前解放の手順を示している: <-----P procedure fails-------> <-------P procedure succeeds---> REQUESTING NBNS REQUESTING NBNS M-NODE M-NODE NAME RELEASE REQUEST NAME RELEASE REQUEST --------------------------> ------------------------> NEGATIVE RELEASE RESPONSE POSITIVE RELEASE RESPONSE <-------------------------- <------------------------- OTHER M-NODES NAME RELEASE DEMAND ------------------------> 15.5. 名前維持の処理 15.5.1. 名前の更新 名前の更新の処理は、以下のような場合に行なわれる: a) NBNS ノードが P ノードか M ノードが「黙って」停止したことを 検出する。これにより、それらのノードが所有していた名前をデー タベースから削除することが可能になる。 b) NBNS が停止した場合、再起動時にデータベースを再構築すること が必要となる。 c) ネットワークが分断されていた場合、ネットワークが再接続され た時点で、NBNS はデータベースを更新することが必要となる。 P および M の各ノードは、登録した各々の名前について、定期的に NAME REFRESH REQUEST を送信する義務がある。各々の更新パケットには、その ノードによって正常に登録されている名前が一つずつ含まれている。この NetBIOS Working Group [Page 45] RFC 1001 March 1987 パケットの間隔は、名前が最初に登録される際に、 NBNS サーバと終端ノー ドとの間でネゴシエーションされる。名前が登録される際に、終端ノード は更新間隔の値を提示する。NBNS ノードはその値を修正した上で、応答パ ケットに含めることが可能である。NBNS ノードは終端ノードに対する応答 パケット中に更新間隔の値として「無期限」を設定することにより、終端 ノードに対して更新パケットの送信が不要であることを通知することも可 能である。終端ノードは、NBNS から返却された更新間隔の値を、実際の 更新間隔の値として使うことが必須である。 あるノードが NAME REFRESH REQUEST を送信する場合は、否定応答の受信 に対しても対応可能になっていることが必須である。これは、NBNS が要求 された名前がすでに他のノードによって所有されていることを確認した際 などに起こりうる。否定応答を受信した場合、終端ノードはその名前が競 合状態にあるものとして扱う必要がある。この状態のエントリは、名前の 競合が検出された場合と同様に扱う必要がある。名前の更新について、以 下の表に図示する: <-----Successful Refresh-----> <-----Unsuccessful Refresh----> REFRESHING NBNS REFRESHING NBNS NODE NODE NAME REFRESH REQUEST NAME REFRESH REQUEST ------------------------> -----------------------> POSITIVE RESPONSE NEGATIVE RESPONSE <------------------------ <----------------------- ! ! V MARK NAME IN CONFLICT 15.5.2. 名前のチャレンジ 名前のチャレンジは、NAME QUERY REQUEST を任意のタイプの終端ノードに 対して送信することで行なわれる。POSITIVE NAME QUERY RESPONSE が返却 された場合、そのノードは名前を所有している。NEGATIVE NAME QUERY RESPONSE が返却された場合や、応答がなかった場合、終端ノードはその名 前を所有していないものとみなされる。 名前のチャレンジは NBNS ノードによっても、終端ノードによっても行な われうる。終端ノードが名前登録パケットを送信した際に、NBNS ノードは チャレンジの処理を行なうことがある。NBNS ノードは終端ノードに対して チャレンジを行なうように要求することも可能である。その場合、NBNS は、 END-NODE CHALLENGE RESPONSE パケットを終端ノードに対して返却するこ とで、所有者の疑いのあるノードに対するチャレンジの実行を指示する。 名前のチャレンジ処理は、終端ノードに対する通常の NAME QUERY REQUEST パケットによって行なわれ、特別なパケットが送出されるわけではない。 この処理に特有のパケットは、NBNS が終端ノードに対して、チャレンジの NetBIOS Working Group [Page 46] RFC 1001 March 1987 処理をさせる際に終端ノードに対して送出する、END-NODE CHALLENGE RESPONSE だけである。 15.5.3. 名前の競合の解決 M もしくは P ノードから NBNS に対する更新リクエストにより、名前の競 合状態が検出されることがある。この場合、NAME REFRESH REQUEST の応答 は、NAME REGISTRATION RESPONSE となることが必須である。ただし、オプ ションとして、NBNS は NAME CONFLICT DEMAND や NAME RELEASE REQUEST を、更新を行なっているノードにお対して送信することもできる。NAME CONFLICT DEMAND を受信したノードは、該当する名前を競合状態としなけ ればならない。最終的に、ノードの利用者に対して競合状態にあることが通 知されることになる。NAME RELEASE REQUEST を受信したノードは、その名 前をローカルな名前テーブルから完全に消去しなければならない。これに より、競合状態にある名前がノードから消去される。なお、該当の名前を 利用している既存のセッションが、これにより切断されることはない。 以下に、NBNS が競合を検知し、それを是正する際の動きを図示する: REFRESHING NODE NBNS NAME REFRESH REQUEST -----------------------------------------> NEGATIVE NAME REGISTRATION RESPONSE <----------------------------------------- NAME CONFLICT DEMAND <----------------------------------------- OR NAME RELEASE REQUEST <----------------------------------------- POSITIVE/NEGATIVE RELEASE REQUEST -----------------------------------------> 15.6. アダプタステータス処理 アダプタステータスは、以下のようにして取得される: 1. 終端ノード(群)の IP アドレスを取得するための名前の問い合わ せ処理を実行する 2. 対象となる終端ノード全てに対して処理が行なわれるまで繰り返す a. 指定した中から1台の終端ノードを選択する b. UDP を用いて NODE STATUS REQUEST を終端ノードに送信する NetBIOS Working Group [Page 47] RFC 1001 March 1987 c. NODE STATUS RESPONSE を待って待機する (一定時間内にレ スポンスがなかった場合、UCAST_REQ_RETRY_COUNT 回ステッ プ b を繰り返した後、ステップ a に戻る)。 d. レスポンス中の truncation ビットが設定されていない場合、 レスポンス中にはノードステータスが含まれている。ステー タスをユーザに返却し、処理を終了する。 e. truncation ビットが設定されていた場合、レスポンスのパ ケットに格納しきれなかったため、ステータスの一部のみが 返却されている。レスポンスを行なう側は、IP データグラ ムの長さが、MAX_DATAGRAM_LENGTH を超過した場合にこのフ ラグを設定する。ステータスをユーザに返却し、処理を終了 する。 3. ユーザにエラーを返却する。ステータスは取得されない。 上記のステップ 2 を全てのノードに対して繰り返すことは、オプションで あり、必須ではない。 以下は、成功したアダプタステータス処理の手順例である: REQUESTING NODE NAME OWNER NAME QUERY REQUEST -----------------------------------------> POSITIVE NAME QUERY RESPONSE <----------------------------------------- NODE STATUS REQUEST -----------------------------------------> NODE STATUS RESPONSE <----------------------------------------- 16. NetBIOS セッションサービス NetBIOS セッションサービスは、宛先の名前に対して 1 つ以上の IP アド レスが確認されてから開始される。この IP アドレスは、NetBIOS 名前問 い合わせ処理や、ローカル名前テーブルやキャッシュといった方法で取得 される。 NetBIOS セッションサービスの処理・パケット・プロトコルは、すべての 終端ノードのノードタイプで同一である。この処理は、直接の(ポイントツー ポイントの)通信である。 NetBIOS Working Group [Page 48] RFC 1001 March 1987 16.1. NetBIOS セッションサービスの概要 セッションサービスは、大きく以下のフェーズで行なわれる: セッションの確立 - 呼出元の名前の TCP ポート・IPアドレスが確定さ れ、遠隔のマシンとの間に TCP コネクションが確立される。 セッションの保持 - NetBIOS のデータメッセージが、セッション上でや りとりされる。ノードの設定によっては、キープアライブパケットも やりとりされる場合がある。 セッションのクローズ - (セッションを保持している)いずれかの側がセッ ションをクローズするか、いずれかの側が停止したと判断されると、 セッションはクローズする。 16.1.1. セッション確立フェーズの概要 終端ノードは、何らかの方法(通常は名前問い合わせ処理や、ローカルな キャッシュ)で IP アドレスを取得した相手ノードや、宛先の名前を所有し ているノード群に対して、セッションの確立を開始する。 各終端ノードは、well-known なサービスポートである SSN_SRVC_TCP_PORT で TCP の LISTEN を行なうことで、NetBIOS セッションリクエストを待ち 受ける。着呼する各 TCP コネクションは、それぞれ独立の NetBIOS セッ ション確立の試行を意味する。NetBIOS セッションサーバ自体はアプリケー ションではなく、着呼する TCP コネクションを受け付ける。 一度 TCP コネクションが開かれると、呼出元のノードは、セッションサー ビスの要求パケットを送出する。このパケットには、以下の情報が含まれ ている: - 呼出元の IP アドレス (注意を参照のこと) - 呼出元の NetBIOS 名 - 呼出先の IP アドレス(注意を参照のこと) - 呼出先の NetBIOS 名 注意: IP アドレスは、TCP サービスのインタフェース経由で取得される。 セッションサービスの要求パケットが NetBIOS サーバに到着した際は、以 下の状況のいずれかが考えられる: - 着呼した呼出しに対して NetBIOS LISTEN が行なわれており、セッショ ンの確立を進めるのに必要なリソースが存在している。 - 着呼した呼出しに対して NetBIOS LISTEN が行なわれているが、セッ ションの確立を進めるのに必要なリソースが存在していない。 NetBIOS Working Group [Page 49] RFC 1001 March 1987 - 呼出先の名前が、呼出元のノードに存在しているものの、着呼した呼 出に対応する NetBIOS LISTEN が存在していない。 - 呼出先の名前は、呼出先のノードに存在しない 最初の状況以外、拒否の応答が TCP コネクションを通じて呼出元に送り返 される。その後 TCP コネクションはクローズし、セッションは終了する。 再試行を行なうかどうかは、呼出元に一任されている。グループ名に対す る再試行の場合、呼出元は同じアドレスに再試行を行なう代わりに、グルー プの別のメンバーに対して試行を行なう。ユニーク名の場合、呼出先の名 前が呼出先ノードで登録されていない場合を除き、呼出元は直ちに同じ IP アドレスを使って再試行を行なう。この場合、NetBIOS 名の名前解決も再 度行なわれるべきである。 対応する LISTEN が存在しており、必要なリソースが存在している場合、 セッションのサーバは、現在の TCP コネクション上で NetBIOS データセッ ションを開始する。それ以外の場合、セッションのサーバは、呼出元を別 の TCP ポート(および IP アドレス)にリダイレクトし、「呼出先変更 (retarget)」を行なう。 呼出元がリダイレクトされた場合、呼出元は新たにセッションの確立を開 始するが、「呼出先変更」レスポンスにあった IP アドレスと TCP ポー トに対して行なう。この場合、TCP コネクションが再度作成され、呼出元 と呼出先のノードが、自身の情報を交換する。呼出先では、呼出を受けつ けるか、拒否するか、もしくは再度リダイレクションを行なう。 この仕組みは、オープンしている TCP コネクションをプロセス間で転送で きないホストが、中央のセッションサーバであるという前提に基づいてい る。NetBIOS の呼出を受信しようとするアプリケーションは、一時的な TCP ポート番号を取得し、そのポートに対して不特定からの受信処理を開 始しするとともに、そのポート番号と NetBIOS 名の情報を、NetBIOS LISTEN 処理を通じて、NetBIOS セッションサーバに送信する。呼出が発生 すると、セッションサーバは、呼出元をアプリケーションの TCP ソケット に対して「呼出先変更」を行なう。呼出元は、そのアプリケーションに 対して、新規に呼出しを行なう。アプリケーションは、少なくとも呼出先 からの通信を受信して、呼出を受け入れるか拒否するまでは、責任を持っ てセッションサーバを偽装する責任がある。 16.1.1.1. 「呼出先変更」後の再試行 呼出元のノードは、「呼出先変更」処理で転送されたノードに対するセッ ションの確立が不可能であると判断する場合がある。「呼出先変更」は 多重に行なわれる場合もあるため、呼出元は最初のノードに対する再試行 を行なうべきか、中間の「呼出先変更」が行なわれたポイントに戻るべ きかという問題がある。呼出元は任意の方式を用いることができる。この NetBIOS Working Group [Page 50] RFC 1001 March 1987 方式に関する議論は、付録B の「「呼出先変更」アルゴリズム」で行なわ れている。 16.1.1.2. グループ名に対するセッションの確立 グループ名に対するセッションの確立については、幾つか考慮すべき点が ある。NetBIOS CALL がグループ名に対して行なわれた場合、名前の問い合 わせにより、そのグループのメンバーの一覧(不完全なものかも知れない) が、返却される。呼出元のノードは、リストから 1 つのメンバーを選択し て、セッションの確立を試行する。これが失敗した場合、呼出元のノード は別のメンバーを選択して、再度試行を行なう。 セッションサービスが、グループのいずれか 1 台のメンバに対してセッショ ンの確立を試行する際に、そのメンバが、該当のグループ名で LISTEN を 行なっているという保証はない。これは、呼出先ノードが名前を所有して いたり、処理を行なっていたりする場合も同様である。 16.1.2. 確立状態フェーズの概要 NetBIOS データのメッセージは確立状態においてやりとりされる。NetBIOS メッセージはユーザデータの前にメッセージヘッダを付加して送出され、 TCP コネクション上をヘッダとユーザデータが伝達される。受信側はヘッ ダを削除して、データを NetBIOS の利用者に対して引き渡す。 いずれかのノードや伝送路のネットワークにより、異常を検出するために、 「session keep alive」パケットが確立状態フェーズの間、定期的に送出 されることもある。 TCP コネクションの下層に異常が発生した場合は、リセット、タイムアウ ト、あるいはその他の異常のいずれであっても、NetBIOS セッションを切 断させる。 16.1.3. セッション終了フェーズの概要 ユーザがセッションの終了を希望した場合、もしくはセッションサービス 側でリモートの通信先が TCP コネクションを正規に終了したことを検出し た場合、NetBIOS セッションは正常終了する。セッションサービスがコネ クションの喪失を検出した場合、NetBIOS セッションは異常終了する。コ ネクションの喪失は、セッションサービスや TCP の keep-alive 機能、 SESSION MESSAGE の送信処理の失敗によって検出される。 ユーザがセッションの終了をリクエストした場合、サービスは、まず TCP コネクションの受け入れを終了しようとする。SSN_CLOSE_TIMEOUT 時間内 にコネクションを終了させることができなかった場合、TCP コネクション は切断される。TCP コネクションがどのように終了したかに関わらず、 NetBIOS セッションサービスは、常に NetBIOS セッションを終了させる。 セッションサービスが TCP からコネクションの終了要求を受信したという 情報を受け取った場合、TCP コネクションと NetBIOS セッションは直ちに 終了し、ユーザはセッションが喪失したという情報を受け取る。終了情報 NetBIOS Working Group [Page 51] RFC 1001 March 1987 受信するまでに受信した全てのデータは、可能な限り、セッションのユー ザに配送されるべきである。 16.2. セッション確立フェーズ 以下の図では、呼出元ノードによる接続先の名前の名前問い合わせ処理は 正常に行なわれたという前提の元に記載している。 最初の図では、受信側によって「呼出先変更」処理が行なわれなかった場合 のセッションの確立成功時のネットワークレベルの手順について示してい る。TCP コネクションは、最初に well-known な NetBIOS セッションサー ビスの TCP ポートである SSN_SRVC_TCP_PORT で確立される。その後、呼 出元は SESSION REQUEST パケットを受信側との間で確立した TCP セッショ ンを使って送信する。SESSION REQUEST には、呼出元の名前と受信側の名 前とが含まれている。受信側は、POSITIVE SESSION RESPONSE を返却する ことで、呼出元に対してこの TCP コネクションをデータ転送フェーズにす ることを承諾したことを伝達する。 CALLER LISTENER TCP CONNECT ====================================> TCP ACCEPT <=================================== SESSION REQUEST ------------------------------------> POSITIVE RESPONSE <----------------------------------- 二番目の図では、受信側によって「呼出先変更」処理が行なわれた場合のセッ ションの確立成功時のネットワークレベルの手順について示している。セッ ションの確立処理は、受信側が SESSION REQUEST に対する応答を返却する ところまで同一である。受信側は、受信処理部と実際の受信者という 2 つ にわかれるが、SESSION RETARGET RESPONSE を呼出元に返却する。この応 答により、呼出は受け付けられるが、データを転送する TCP コネクション は別の IP アドレスと TCP ポートに対して行なわれる。呼出元は最初の TCP コネクションを終了した後で、新しい IP アドレスと TCP ポートに対 してセッションの確立処理を再度行なう。新しい受信側は、POSITIVE SESSION RESPONSE を返却して、このコネクションがデータ転送フェーズに する。 CALLER LISTEN PROCESSOR LISTENER TCP CONNECT =============================> TCP ACCEPT <============================= SESSION REQUEST -----------------------------> NetBIOS Working Group [Page 52] RFC 1001 March 1987 SESSION RETARGET RESPONSE <----------------------------- TCP CLOSE <============================= TCP CLOSE =============================> TCP CONNECT ====================================================> TCP ACCEPT <==================================================== SESSION REQUEST ----------------------------------------------------> POSITIVE RESPONSE <---------------------------------------------------- 三番目の図では、受信側によってセッション開設要求が拒否された場合の ネットワークレベルの手順について示している。拒否は、「呼出先変更」 処理を行なっていない受信側と行なっている受信側のいずれの場合も起こり うる。TCP コネクションが SSN_SRVC_TCP_PORT で確立された後で、呼出元 が TCP コネクション上で SESSION REQUEST を送信する。受信側は、その 名前で待ち受けていないか、待ち受けている NetBIOS listen は別の呼出 元用のものである。従って、受信側は NEGATIVE SESSION RESPONSE を送信 し、TCP コネクションをクローズする。 CALLER LISTENER TCP CONNECT ====================================> TCP ACCEPT <=================================== SESSION REQUEST ------------------------------------> NEGATIVE RESPONSE <----------------------------------- TCP CLOSE <=================================== TCP CLOSE ====================================> 四番目の図は、受信側によって「呼出先変更」処理が行なわれた後のセッ ション確立が失敗した場合の手順について示している。呼出先の変更が行 なわれて、それまでの TCP コネクションが終了した後で、呼出元は新しい IP アドレスと TCP ポートに対する TCP コネクションを確立しようとする。 コネクションは、対象のポートが利用できない、送信先のノードが起動し ていないなどの理由で失敗する。ポートが利用できないという状況は、別 の呼出元がすでに受信側と TCP コネクションを確立している際に発生する。 付録B「「呼出先変更」アルゴリズム」に関連する実装についての提案が記 述されている。 NetBIOS Working Group [Page 53] RFC 1001 March 1987 CALLER LISTEN PROCESSOR LISTENER TCP CONNECT =============================> TCP ACCEPT <============================= SESSION REQUEST -----------------------------> REDIRECT RESPONSE <----------------------------- TCP CLOSE <============================= TCP CLOSE =============================> TCP CONNECT ====================================================> CONNECTION REFUSED OR TIMED OUT <=================================================== 16.3. セッションデータ転送フェーズ 16.3.1. データのカプセル化 NetBIOS データのメッセージは確立状態においてやりとりされる。NetBIOS メッセージはユーザデータの前にメッセージヘッダを付加して送出され、 TCP コネクション上をヘッダとユーザデータが伝達される。受信側はヘッ ダを削除して、データを NetBIOS の利用者に対して引き渡す。 16.3.2. session keep alive ノードの異常や、ネットワークの分断を検出するために、「session keep alive」パケットが確立状態フェーズの間、定期的に送出される。到達した session keep alive パケットはノードによって破棄される。 session keep alive のタイマは、セッション毎に維持される。このタイマ は、何らかのデータがセッションの相手との間で送受信された際に、初期 化される。タイマ時間を超過すると、NetBIOS session keep alive パケッ トが TCP コネクション上で送出される。keep alive パケットを送出する ことで、TCP コネクション上でデータがやりとりされ、間接的にコネクショ ンがまだ有効であることを TCP に検出させる。 多くの TCP の実装では、ほぼ同様の機能を持つ TCP keep alive機構を実 装しているため、NetBIOS session keep alive は設定可能なオプションと なっている。NetBIOS keep alive 機構は TCP keep alive が利用できない 場合にのみ利用することが望ましい。 TCP keep alive と異なり、NetBIOS session keep alive は NetBIOS 上の 通信先からのレスポンスを受信する必要はない。すなわち、NetBIOS session NetBIOS Working Group [Page 54] RFC 1001 March 1987 keep alive を送信できるということで、通信相手やコネクションがまだ有 効であるということが充分確認できるということである。 相互接続性のために必要なことは、session keep alive を受信したら、そ れを破棄すべきであるということだけである。 17. NetBIOS データグラムサービス 17.1. NetBIOS データグラムサービスの概要 各 NetBIOS データグラムには送信先と送信元の名前が含まれる。NetBIOS データグラムを送信する際、データグラムサービスは送信先 NetBIOS 名の attribute や IP アドレスを取得するため、名前問い合わせの処理を行な う必要がある (この情報は、以降の NetBIOS データグラムに対する名前問 い合わせのオーバーヘッドを削減するため、キャッシュされることもある)。 NetBIOS データグラムは UDP パケットを用いて送信される。NetBIOS デー タグラムが単一の UDP パケットで送信できない大きさの場合、複数の UDP パケットに分割されることもある。 終端ノードは、自ノードが所有していない名前に対する NetBIOS データグ ラムを受信することもある。そうしたデータグラムは破棄されなければな らない。名前がユニーク名の場合は、NetBIOS データグラムの送信元に DATAGRAM ERROR パケットが送信される。 17.1.1. ユニキャスト、マルチキャスト、ブロードキャスト NetBIOS データグラムは、ユニキャスト、マルチキャスト、ブロードキャ ストのいずれもとりうる。ユニーク名に対する NetBIOS データグラムはユ ニキャストになる。グループ名に対する NetBIOS データグラムは、そのグ ループの実際のメンバー数に関わらず、マルチキャストになる。「Send Broadcast Datagram」コマンドを使って送信される NetBIOS データグラム はブロードキャストになる。 17.1.2. NetBIOS データグラムの分割 NetBIOS データグラムのヘッダとデータの和が、 UDP パケットの最大値を 越える大きさになった場合、NetBIOS データグラムは伝送前に分割され、 受信者側で再構成されることが必須である。 NetBIOS データグラムは、以下の内容から構成されている: - (最小) 20 バイトの IP ヘッダ - 8 バイトの UDP ヘッダ - 14 バイトの NetBIOS データグラムヘッダ - NetBIOS データグラムのデータ NetBIOS データグラムのデータセクションは、以下の部分からなる: - 送信元 NetBIOS 名 (最大 255 バイト) - 受信先 NetBIOS 名 (最大 255 バイト) - NetBIOS のユーザデータ (最大 512 バイト) NetBIOS Working Group [Page 55] RFC 1001 March 1987 2 箇所ある NetBIOS 名のフィールドは、第 2 レベルのエンコード形式 (14 章を参照のこと) になっている。 NetBIOS データグラムの最大値は 1064 バイトである。IP データグラムの 最大値は、576 バイト以上である。そのため、NetBIOS データグラムが単 一の IP データグラムに収まらない場合もある。この場合、NetBIOS デー タグラムの分割が必要となる。 IP データグラムの最大値が 576 オクテットかそれ以上のネットワークに おいて、NetBIOS データグラムの分割数は、多くても 2 つまでである。た だし、プロトコルやパケットのフォーマットは、3 つ以上の分割にも対応 している。 NetBIOS データグラムが分割された場合、IP, UDP, NetBIOS データグラム のヘッダは、各フラグメント(分割されたデータグラム)に存在する。 NetBIOS データグラムのデータセクションは、生成される UDP データグラ ムに分割して格納される。各フラグメントに存在するデータセクションに、 重複はない。NetBIOS データグラムのヘッダで変化するのは、FLAGS と OFFSET フィールドだけである。 FLAGS フィールドの FIRST ビットは、これが先頭のフラグメントであるか どうかを示す。FLAGS フィールドの MORE ビットは、更にフラグメントが 存在するかどうかを示す。 OFFSET フィールドは、NetBIOS データグラムのデータセクションの先頭か ら、該当のフラグメントのデータセクションの先頭までのオフセットを示 す。最初のフラグメントでは、この値は 0 である。それ以降のフラグメン トの場合、OFFSET は、先行する各フラグメントのデータセクションのバイ ト数の合計値になる。 NetBIOS データグラムが分割されなかった場合: - FIRST = TRUE - MORE = FALSE - OFFSET = 0 NetBIOS データグラムが分割された場合: - 先頭のフラグメント: - FIRST = TRUE - MORE = TRUE - OFFSET = 0 - 中間のフラグメント: - FIRST = FALSE - MORE = TRUE - OFFSET = 合計値(フラグメントに含まれる NetBIOS データの) - 最後のフラグメント: - FIRST = FALSE - MORE = FALSE NetBIOS Working Group [Page 56] RFC 1001 March 1987 - OFFSET = 合計値(フラグメントに含まれる NetBIOS データの) 中間のフラグメントの相対位置は、OFFSET の値により、確認することがで きる。 NBDD は、最初のフラグメントの宛先の名前を記憶することが必須であり、 これにより、ある NetBIOS データグラムの後続のフラグメントを中継する。 名前の情報の対応づけは、パケット中のトランザクション ID、DGM_ID、送 信元IPといったフィールドによって行なわれる。この情報は、最後のフラ グメントが処理されるか、最初のフラグメントを受信してから FRAGMENT_TO 時間が経過した時点で、NBDD から消去することができる。 17.2. B ノードによる NetBIOS データグラム 特定の宛先に対する(ブロードキャストでない) NetBIOS データグラムにつ いて、B ノードはデータグラムを送信する前に宛先の名前問い合わせを行 なう。(名前問い合わせは、以前の問い合わせで得た情報がキャッシュにあ る場合は省略される。) 問い合わせの結果返却された名前のタイプがユニー クだった場合、データグラムはその名前の所有者に対するユニキャストと なる。名前のタイプがグループだった場合、データグラムの送信先アドレ スはブロードキャストアドレスとなり、ブロードキャスト領域全体に対す るブロードキャストとして送信される。 受信したノードは、宛先の名前によってデータグラムを常に選別する。宛 先の名前をそのノードが所有していないか、 RECEIVE DATAGRAM というユー ザ処理が該当の名前に対して発行されていない場合、そのデータグラムは 破棄される。ユニーク名の宛先のデータグラムの場合、宛先の名前がノー ドによって所有されていない場合、受信したノードは DATAGRAM_ERROR パ ケットを送出する。このエラーパケットは、DGM_SRVC_UDP_PORT ポートか ら送出され、問題のデータグラムを発行した発行元IPと発行元ポートに対 して送出される。グループ名の宛先のデータグラムを受信したが、その名 前を所有していない場合、受信したノードはそのデータグラムを破棄する。 ブロードキャストの NetBIOS データグラムには、特定の宛先がないため、 B ノードは 、データグラムの送信先アドレスをブロードキャストアドレス として、ブロードキャスト領域全体に対して DATAGRAM SERVICE パケット を送信する。受信したノードがこのデータグラムをブロードキャストの NetBIOS データグラムとして識別できるようにするため、NetBIOS 名とし て、「*」(16進数で 2A)とその後に 15 バイトの 16進数で 00 が続いたも のが、宛先の NetBIOS 名として用いられる。この名前に第 2 レベルのエ ンコーディングが行なわれる前に、NetBIOS スコープ識別子が名前に付加 される。例えば、スコープ識別子が「NETBIOS.SCOPE」だった場合、第 1 レベルのエンコーディングは以下のようになる: CKAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA.NETBIOS.SCOPE [2] によると、ユーザは「*」から始まる NetBIOS 名を使ってはならない。 NetBIOS ブロードキャストデータグラムを受信する、ブロードキャスト領 NetBIOS Working Group [Page 57] RFC 1001 March 1987 域内の各ノードについて、RECEIVE BROADCAST DATAGRAM というユーザ処理 が発行されている全てのノードに対して、NetBIOS データグラムからのデー タが複製されて、配送される。この処理が発行されていない場合、ノード は黙ってデータグラムを破棄する。 17.3. P ノードや M ノードにおける NetBIOS データグラム P および M ノードでは、 NetBIOS データグラムの配布に IP ブロードキャ ストを用いることができない。 B ノードと同様、P および M ノードの場合も、送信先の名前がグループ名 かユニーク名かを判断するため、名前の問い合わせを行なうか、キャッシュ 済の情報を利用することが必須である。 ユニーク名に対するデータグラムは、B ノードの場合と同様に、 P および M ノードの場合も、送信先へ直接ユニキャストで送られる。 グループ名や NetBIOS ブロードキャストに対するデータグラムは、 NBDD へユニキャストで送信される。 NBDD は、そのデータグラムを送信先とし て指定された各ノードに対して転送する。 前述したブロードキャストの NetBIOS 名(「*」)を含む、幾つかのNetBIOS 名に対して、NBDD が NetBIOS データグラムを送信することができない場 合がある。終端ノードは、NBDD がデータグラムを指定された名前に対して 中継することが可能かどうかを確認するための問い合わせを行なうことが 可能である。データグラムやそのフラグメントを NBDD に送信する前に、P および M ノードは DATAGRAM SERVICE の DESTINATION_NAME の情報を含め た DATAGRAM QUERY REQUEST パケットを NBDD に送信することも可能であ る。NBDD は、そのデータグラムを指定された宛先名に対して中継すること が可能な場合は、DATAGRAM POSITIVE QUERY RESPONSE で応答する。肯定応 答を受信した終端ノードは、データグラムを NBDD に対してユニキャスト で送信する。NBDD がデータグラムを問い合わせで指定された宛先名に対し て送信することができない場合、DATAGRAM NEGATIVE QUERY RESPONSE パケッ トが返却される。NBDD がデータグラムを配布することができない場合、終 端ノードはNBNS から名前の所有者のリストを取得し、データグラムを所有 者の各々に対して直接送信することを選択しても良い。 NBDD は DATAGRAM QUERY REQUEST パケットに対して応答が可能であること が必須である。この応答は常に肯定であってもよい。ただし、P ノードや M ノードが問い合わせ機能を実装して利用するかどうかはオプションであ る。実装によっては、NBDD に対して中継可能であるかどうかを問い合わせ ずに常に NetBIOS データグラムを NBDD に対してユニキャストしてもよい。 上記で記述したデータグラムの問い合わせ機能を除き、NBDD はデータグラ ムが転送可能かどうかについてを示す応答は行なわない。 18. ノードの設定パラメータ - B ノード: - ノードの永続的なユニーク名 - IGMP の利用可否 - 利用するブロードキャストアドレス NetBIOS Working Group [Page 58] RFC 1001 March 1987 - NetBIOS セッションキープアライブを必要とするか - (フラグメンテーション制御用の) 利用可能な UDP データフィールド長 - P ノード: - ノードの永続的なユニーク名 - NBNS の IP アドレス - NBDD の IP アドレス - NetBIOS セッションキープアライブを必要とするか - (フラグメンテーション制御用の) 利用可能な UDP データフィールド長 - M ノード: - ノードの永続的なユニーク名 - IGMP の利用可否 - 利用するブロードキャストアドレス - NBNS の IP アドレス - NBDD の IP アドレス - NetBIOS セッションキープアライブを必要とするか - (フラグメンテーション制御用の) 利用可能な UDP データフィールド長 19. 最低限の条件 マルチベンダ間の相互接続性を確保する上で、この仕様に準拠した最低限 の条件として、以下の規定に準拠することが必須である: a) ブロードキャスト領域内でのみ機能するように設計されるノードは、 B ノードの仕様を満たすことが必須である。 b) インターネット領域内でのみ機能するように設計されるノードは、 P ノードの仕様を満たすことが必須である。 NetBIOS Working Group [Page 59] RFC 1001 March 1987 参考 [1] "Protocol Standard For a NetBIOS Service on a TCP/UDP Transport: Detailed specifications", RFC 1002, March 1987. [2] IBM Corp., "IBM PC Network Technical Reference Manual", No. 6322916, First Edition, September 1984. [3] J. Postel (Ed.), "Transmission Control Protocol", RFC 793, September 1981. [4] MIL-STD-1778 [5] J. Postel, "User Datagram Protocol", RFC 768, 28 August 1980. [6] J. Reynolds, J. Postel, "Assigned Numbers", RFC 990, November 1986. [7] J. Postel, "Internet Protocol", RFC 791, September 1981. [8] J. Mogul, "Internet Subnets", RFC 950, October 1984 [9] J. Mogul, "Broadcasting Internet Datagrams in the Presence of Subnets", RFC 922, October 1984. [10] J. Mogul, "Broadcasting Internet Datagrams", RFC 919, October 1984. [11] P. Mockapetris, "Domain Names - Concepts and Facilities", RFC 882, November 1983. [12] P. Mockapetris, "Domain Names - Implementation and Specification", RFC 883, November 1983. [13] P. Mockapetris, "Domain System Changes and Observations", RFC 973, January 1986. [14] C. Partridge, "Mail Routing and the Domain System", RFC 974, January 1986. [15] S. Deering, D. Cheriton, "Host Groups: A Multicast Extension to the Internet Protocol", RFC 966, December 1985. [16] S. Deering, "Host Extensions for IP Multicasting", RFC 988, July 1986. NetBIOS Working Group [Page 60] RFC 1001 March 1987 付録 A この付録には、技術的なテーマが含まれている。これは NetBIOS over TCP の仕様上必須のものではない。 Internet Group Muticast との連携 この RFC で記述された NetBIOS over TCP システムは、現在インターネッ トで開発中の Internet Group Multicast システムとの連携が容易に行な えるようになっている。 この RFC の本文中にて、ブロードキャスト領域と表現しているものは、単 一の MAC アドレスレベルでブリッジされた「B-LAN」を想定している。し かし、固定的な Internet Multicast Group を生成することで、これらの プロトコルは拡張されたブロードキャスト領域上でも動作する。 各ブロードキャスト領域が、固定的な Internet Multicast Group を形成 する。このマルチキャストグループのアドレスは、 B および M ノードか らは BROADCAST_ADDRESS として利用される。 ブロードキャスト領域をマルチキャストグループ単位のものみなすために は、幾つかの仕様追加および制限事項の定義が必須である。 A-1. B および M ノードに必要なプロトコル IGMP ベースのブロードキャスト領域上で動作する B ノードおよび M ノー ドは、 IP 層のソフトウェアに IGMP サポートが必須である。これらのノー ドは NetBIOS を有効とする前に、 IGMP グループへ参加するため IGMP join 処理を実行することが必須である。 A-2. 制限事項 ブロードキャスト領域が重複することがある。そのため、終端ノードでは 受信するすべてのブロードキャストパケットについて、 NetBIOS スコープ 識別子が適切なものであることを確認することが必須である。 NetBIOS ブロードキャストプロトコルは、平均通信時間が短くパケットロ スもあまり発生しないようなネットワークを前提として設計されている。 IGMP ベースのブロードキャスト領域もこうした前提のもとに構成する必要 がある。この制限事項により、 IGMP ブロードキャスト領域はキャンパス ネットワークなどの高速なルータで接続された環境や内部ルータで接続さ れた環境に制限されるであろう。大陸をまたがるようなブロードキャスト 領域を必要条件として提示するのは、現実的ではないであろう。 NetBIOS Working Group [Page 61] RFC 1001 March 1987 付録 B この付録には、技術的なテーマが含まれている。これは NetBIOS over TCP の仕様上必須のものではない。 実装についての考察 B-1. 実装モデル 機能を実装するシステムでは、システム上の NetBIOS アプリケーションか ら利用できる何らかの NetBIOS サービスの存在が必須である。 NetBIOS over TCP のアーキテクチャを分析するにあたり、NetBIOS サービ スの実装形態として以下の 3 つのモデルを利用した: 1. サービス・アプリケーション統合モデル NetBIOS サービスおよびアプリケーションの両方が同一プロセスに含 まれる。システム内でのプロセス間通信は存在しない。すべての通信 はネットワーク越しのものである。複数のアプリケーションが同時に NetBIOS サービスにアクセスすることが必要な場合、それらは単一の プロセスとして存在することが必須である。 2. カーネル共通モジュールモデル NetBIOS サービスは、OS の一部として存在する (デバイスドライバ やフロントエンドプロセッサなどとして)。NetBIOS アプリケーショ ンは、OS 上の通常のアプリケーションプロセスである。共通的モジュー ルの NetBIOS サービスには、名前テーブル、待ち受けテーブルなど、 アプリケーションが NetBIOS サービスを利用するのに必要な、すべ ての情報が存在している。 3. 非カーネル共通モジュールモデル NetBIOS サービスは OS のアプリケーションプロセスとして実装され る。NetBIOS アプリケーションは OS 上の別のアプリケーションプロ セスになる。サービスとアプリケーションとは、OS のプロセス間通 信経由でデータをやりとりする。マルチプロセッサの(ネットワーク) OS では、各モジュールが異なる CPU 上に存在することもある。 NetBIOS サービスプロセスには、NetBIOS アプリケーションの動作を 制御するのに必要な全ての共有情報が存在する。アプリケーションが NetBIOS サービスにアクセスするためにはサブルーチンライブラリを 呼び出すことが必要な場合もある。 NetBIOS Working Group [Page 62] RFC 1001 March 1987 いずれの実装モデルの場合も、TCP/IP サービスは OS 中に存在するか、 NetBIOS アプリケーションと NetBIOS サービスプロセス内に分割されて存 在するかのいずれもとりうる。 B-1.1 モデルに依存しない考察 NetBIOS ネームサービスは、NetBIOS 名をホストと対応付ける。さらに、 NetBIOS セッションサービスは、名前をセッションの間特定の TCP ポート と対応付ける。 ネームサービスは各々の Listen の開始や完了を知る必要はない。名前は、 ネームサービスの特定の TCP ポートに対応付けられるものではないため、 セッションサービスは、同じ名前で確立された各セッション毎に別の TCP ポートを利用しても構わない。 NetBIOS セッションのデータ転送フェーズで用いられる TCP ポートは、グ ローバルに well-known なものであっても、ローカルで well-known なも のであっても、一時的なものであっても構わない。どれを利用するかは各々 の実装に任されている。「呼出先変更」機能により NetBIOS セッ ションを、任意の TCP ポートの TCP コネクションに対して、場合によっ ては別の IP ノードのものに対しても割り当てることもできる。 実装によっては、「呼出先変更」機能を使わずに、最初の TCP コネクション 上でセッションを開設し、データ転送フェーズ用の TCP ポートとして セッションサービスのグローバルな well-known TCP ポートを使うことも 可能である。呼出元が常に一時的な TCP ポートを利用できるとは限らない ため、この実装が許容されている。 複雑な呼出側での「呼出先変更」機能は、必要な場合にのみ実装すればよい。 実際のところ、カーネルに実装された NetBIOS サービスの実装などの多く のシステム環境では、到達した呼出の「呼出先変更」は不要であり、むし ろ全ての NetBIOS セッションを一つの well-known な NetBIOS セッショ ンサービスポート上で多重化することになろう。これらの実装は、複雑な 「呼出先変更」機能による負担もなく、呼出元が呼出先変更を強要される こともない。 しかし、全ての呼出元は、発生しうる SESSION RETARGET RESPONSE に対応 できるようにしておくことが必須である。 B-1.2 各モデルのサービス処理 ここまでで定義した各実装モデルに従って、本仕様に基づいた NetBIOS サー ビスを実装することが可能である。 カーネル共通モジュールモデルの場合、名前解決、データグラム、セッショ ンといった全ての NetBIOS サービスは単純化される。全ての情報が一箇所 に集約されるため、情報へのアクセスや修正を簡単に行なうことができる。 NetBIOS セッションを単一のポートあるいは複数のポートで行なうかによっ て、セッションの確立時の手順が非常に複雑になったりすることはない。 NetBIOS メッセージの取得やリクエスト/レスポンスの処理が、ユーザや OS をまたがって行なわれることによるオーバーヘッドの量が、唯一影響す NetBIOS Working Group [Page 63] RFC 1001 March 1987 る点となる。 サービス・アプリケーション統合モデルは、NetBIOS サービスの実装とい う点では、カーネル共通モジュールモデルと非常に類似している。主要な 問題点は、このモデルのシステムに複数の NetBIOS サービスやアプリケー ションが存在した場合の内部的な整合性確保になる。 NetBIOS 名や、データグラムおよびセッションプロトコルでは、エンドポ イントのエンティティが、様々な well-known の TCP および UDP ポート に対して完全なアクセスが可能であることを前提としている。複数の NetBIOS サービスエンティティ、もしくは NetBIOS ライブラリにリンクさ れた複数のアプリケーションが存在する実装では、何らかの内部的な整合 性の確保が必要となる。言い替えると、NetBIOS ポートの利用を定期的に あるアプリケーションから別のアプリケーションに対して変更するといっ たことが必要となる。 典型的な非カーネル共通モジュールモデルの実装においては、3 つの定常 的なシステム共通の NetBIOS サービスプロセスが存在する: - ネームサーバ - データグラムサーバ - セッションサーバ 各サーバは UDP や TCP の well-known ポートからの要求を待機する。各 アプリケーションには、 NetBIOS サービスの一部、通常はライブラリが組 み込まれている。各アプリケーションの NetBIOS サポートライブラリは、 名前の登録、データグラムの送信、待機といった処理要求のため、特定の サーバにメッセージを送信することが必要とされる。 非カーネル共通モジュールモデルでは、プロセス間やセッションサーバとア プリケーション間の通信を TCP コネクションで行なう必要はない。有効な NetBIOS Listen に対する「呼出先変更」処理は、セッションサーバが、ある セッションをアプリケーションの NetBIOS サポートライブラリが提供して おり、割当を行なっているポートに対する TCP コネクションに転送するこ とを可能とする。組み込みまたはカーネルベースの TCP/IP サービスをも つアプリケーションは、「呼出先変更」された接続の要求を受け付け、セッ ションサーバとは独立に処理を継続することが可能である。 Unix(tm) もしくは Posix(tm) において、NetBIOS セッションサーバは到 着するコネクション用のサブプロセスを作成することも可能である。オー プンされたセッションは、fork と exec を経由してファイルディスクリプ タの形で子プロセスに引き渡される。しかし、この方式は非常に限定され たものである。すでに存在しているプロセスが新たな呼出を受け付けるこ とはできない。また呼び出されたプロセスは、セッションサーバのサブプ ロセスにならなければならない。 B-2. 一般 NetBIOS アプリケーションと特権 NetBIOS アプリケーション NetBIOS は、一般的なパーソナルコンピュータなどのオープンシステム環 境で実行するように設計されたため、アプリケーションが特権を保持して NetBIOS Working Group [Page 64] RFC 1001 March 1987 いるかどうかといった概念はそもそも存在していない。多くのマルチユー ザ、マルチタスクの OS のアプリケーションでは、何らかの特権機能が存 在している。この機能により、アプリケーションのシステムのリソースを 取得して使う能力が制限されている。こうしたシステムでは、システムに 対する特権を制限された一般のアプリケーションと、保護されているアカ ウントやリソースへのアクセスができる「スーパーユーザ」権限のある特 権アプリケーションとの両方が NetBIOS サービスにアクセスできるように することが重要である。また、システムの管理者が、ある NetBIOS リソー スへのアクセスを特定の NetBIOS アプリケーションのみに限定できること も重要である。一例を挙げると、NetBIOS サービスベースのファイルサー バは、あるセッションでのみ有効な名前と TCP ポートを持つべきである。 NetBIOS アプリケーションは、別の NetBIOS アプリケーションと通信する ために、最低ふたつのローカルリソース、自身の NetBIOS 名と(通常は)セッ ションが必要である。NetBIOS サービスは NetBIOS アプリケーションが直 接保護されたシステムリソースを利用することを要求できない。例えば、 多くのシステムでは 1024 以下の TCP や UDP ポートを使う際には特権が 必要である。この RFC では NetBIOS ネームサービスおよびセッションサー ビスの実装に、予約されたポートを必要としているが、アプリケーション が直接こうした予約されたポートへアクセスすることを必要としているわ けではない。 ネームサービスの場合、ローカルな名前テーブルの管理アプリケーション は NetBIOS ネームサービス用に予約された UDP ポートへのアクセスが*必 須*である。これは、自身が所有している名前を、ネットワークに対して登 録したり、保持したりするため、ネームサービスに対する UDP パケットの 受信待機を行なう必要があるためである。しかし、この管理アプリケーショ ンは、予約されたポートへのアクセスが制限されているシステム環境で、 一般のユーザアプリケーションとして動作させる必要はない。 内部のネームサーバで、アクセス権による保護を行なう場合、名前の登録、 削除、使用といった特権が必要である。この制限は、NetBIOS サービスプ ロトコルの処理とは独立しており、この実装と別の実装との相互接続性を なくすものではない。 セッションサーバは、セッション確立のために、予約された TCP ポートへ アクセスすることが必要である。しかし、データの送受信を行なうための TCP コネクションが、この予約されたポート経由で行なわれる必要はない。 「呼出先変更」機構により、NetBIOS セッションは別の TCP コネクション、 おそらく呼出先の別のポートに転送される。このポートは 1023 より大き い特権が不要のリソースであってもよい。これにより一般のアプリケーショ ンが実現される。 一方、「呼出先変更」機構により、データの送受信に用いる TCP ポートを保護 されたポートとすることも可能である。これにより、システム管理者の管 理しているポートにアクセスしようとしているアプリケーションが、制限 された TCP ポートを利用することも可能となる。これにより、特権アプリ ケーションが実現される。 実装によっては、セッションの確立に際して、システム内部で保持する情 NetBIOS Working Group [Page 65] RFC 1001 March 1987 報に依存した特別な特権を必要とすることも考えられる。この特権の実装 は、TCP のポート割当によるものである必要はない。例えば、指定された NetBIOS 名を、あるシステムの特権レベルをもったアプリケーションによ るセッションにのみ利用するといったことも可能である。 予約されているポートと予約されていないポートのどちらを使うか、また 名前の登録や使用に際して認証を行なうようにするかどうかといった判断 は、ローカルな実装レベルの判断である。RFC に記載する NetBIOS プロト コルでは、こうした実装は要求しない。 B-3. TCP の利用とセッション KEEP ALIVES KEEP ALIVE はコネクションが存在しているかどうかを確認するために用い られるプロトコルの機能である。リモートのコネクション接続相手に対し てパケットが送信され、レスポンスがあった場合に、コネクションが依然 として機能していると判断される。TCP の KEEP ALIVE は TCP レベルの TCP コネクション上で行なわれ、セッション KEEP ALIVE は NetBIOS セッ ション上で行なわれる。これらのプロトコル処理はコネクションの利用者 からは透過的に行なわれる。利用者が KEEP ALIVE 処理を意識するのは、 失敗時にコネクションが切断されることによってのみである。 NetBIOS の仕様[2] では、セッションが passive と active いずれの状態 にある場合でも、NetBIOS サービスはセッションのユーザに対して、セッ ション切断を通知する必要がある。セッションの利用者が単に待機してい る時に、セッションが切断された場合、NetBIOS サービスはそれをセッショ ンの利用者に通知することが*必須*である。送信処理が行なわれるまで、 利用者に対してコネクションの切断を通知しないでいてはならない。 この要求仕様は、NetBIOS アプリケーションによる不十分で不安定なリソー スの管理を行なうことから生じたものである。あるユーザがNetBIOS Hang Up を行なわずに、クライアントアプリケーションや NetBIOS サービスを 停止させることにより、セッションを終了させた場合、サーバアプリケー ションは割り当てていたリソースをクリーンナップして解放することが望 ましいであろう。レスポンスを受信して、それに応答するだけのサーバア プリケーションは、受動的な状態にある場合でも、セッションが中断され たことの通知が必要である。 この標準で定義されている TCP サービスでは、受動的な状態にある場合、 コネクションの切断を検出することができず、パケットを待ち続ける。 TCP の実装によっては、機能を持っていない実装との互換性を維持した形 で KEEP ALIVE 機能が追加されている。これらの実装は、コネクションの 相手に対して不正なシーケンス番号のパケットを送出する。コネクション の相手は、仕様にしたがって、コネクションの適切なシーケンス番号を含 むパケットで応答することが*必須*である。接続相手から、ある一定の時 間内にレスポンスを受信することができなかった場合、TCP サービスは、 コネクションが切断されていると判断する。 多くの TCP の実装では、 KEEP ALIVE 機能が実装されていないため、 NetBIOS セッションプロトコルには、NetBIOS KEEP ALIVE 機能がオプショ ンとして追加されている。NetBIOS KEEP ALIVE は接続相手からのレスポン スを要請する際に、TCP のプロパティを利用する。KEEP ALIVE という NetBIOS Working Group [Page 66] RFC 1001 March 1987 NetBIOS セッションのメッセージが接続相手から送信される。この結果、 接続相手に対して IP パケットを TCP レベルで送ることができれば、その TCP コネクションは有効である。接続先の TCP パートナが IP パケットに 対して応答するかどうかで、TCP コネクションが切断されているかどうか が TCP 自身によって検出される。そのため、NetBIOS セッションサービス 自身は、セッション KEEP ALIVE メッセージに対して応答を送信せず、単 に無視するだけである。KEEP ALIVE を送出する NetBIOS セッションサー ビスには、TCP コネクションの失敗のみが通知される。特定のレスポンス メッセージを待って待機することはない。 NetBIOS の実装によっては、NetBIOS インタフェースの仕様[2] との互換 性を維持するために、KEEP ALIVE を利用す*べき*である。 サービスの仕様上セッション切断の検出が必要な既存の NetBIOS アプリケー ションや、今後セッション切断の検出の実装を前提として開発されるアプ リケーションでなどをサポートしようとする実装にとって、互換性は特に 重要である。 B-4. 「呼出先変更」アルゴリズム このセクションは、 「呼出先変更」のアルゴリズムに関して、「straight」 と「stack」という 2 つの方式の提案を行なっている。RFC の本文で用い られているアルゴリズムは straight 方式である。それ以外の方式を実装 する場合は、セッション確立時の最大試行回数を考慮することが必須であ る。試行回数は、失敗と判断されるまでに繰り返すことが可能な TCP コネ クト処理の回数である。 straight 方式では、名前問い合わせ処理を通じて返却された最初のノード に対する「呼出先変更」が失敗した際に、セッション確立の処理の再試行 を開始させる。「呼出先変更」の失敗は TCP コネクションの確立にタイム アウトした場合や、NOT LISTENING ON CALLED NAME のエラーコードととも に NEGATIVE SESSION RESPONSE が返却された場合などに発生する。セッショ ン確立の処理において、それ以外のエラーが発生した場合は、名前問い合 わせ処理の送信から、再度処理をやりなおすべきである。 「呼出先変更」の失敗と、名前問い合わせの失敗のいずれの場合でも、最 低でも 2 回の再試行が行なわれる。これにより、セッションサービスには NetBIOS Listen を再確立する機会が与えられるとともに、更に重要なこと として、 NetBIOS スコープ、ローカルの名前サービスや NBNS が、その NetBIOS 名に対する適切な IP アドレスを再学習することが可能となる。 stack 方式も、straight 方式と同様に機能する。ただし、名前問い合わせ 処理に対して応答があった最初のノードに対して再試行を行なう代わりに、 「呼出先変更」が失敗する前に、SESSION RETARGET RESPONSE を送信して きたノードの IP アドレスに対して、再試行を行なう。stack 方式の実装 上、あるホストに対する再試行は、最大でも 2 回に制限される。 NetBIOS Working Group [Page 67] RFC 1001 March 1987 B-5. NBDD サービス NBDD がデータグラムを転送しない場合、NetBIOS ユーザに対しては、グルー プに対するものや、ブロードキャストの NetBIOS データグラムサービスが 提供されない。そのため、問い合わせ要求の実装からは外れるが、否定応 答を受信した際には、メンバの IP アドレスの一覧を取得して、データグ ラムを各々のメンバに対してユニキャストで送信する。 B-6. アプリケーションに関する考察 B-6.1 NetBIOS データグラムの利用 現存する NetBIOS アプリケーションの中には NetBIOS データグラムを独 自のコネクション指向プロトコルの基盤として利用しているものもある。 これは、過剰な NetBIOS 名前問い合わせ処理を発生させ、ネットワーク、 サーバノード、およびその他の終端ノードに負担を掛けるため、新規のア プリケーションではこうした実装は避けることを推奨する。 NetBIOS Working Group [Page 68]