要約

  • RFC 2097では、遠隔端末が相手に特定のNetBIOS名を追加するよう求めた。一つの交渉で、ある名前は成功し、別の名前には具体的な失敗理由が返り得た。
  • NBFCPは相手のクラス、マルチキャストの転送間隔と優先度、各NBFデータグラムに12オクテットのIEEE MACヘッダーが必要かどうかも明示した。
  • OpenedやAdded=0は局所的な証拠にすぎない。広域での一意性、身元、認可、LAN間接続、完全な配送、後続セッション、安全性は証明しない。

遠隔アクセス回線が物理的に生き、PPPのLCPが終了し、Network-Layer Protocolフェーズに入っていても、アプリケーションが使う名前には相手側ネットワーク上の居場所がまだないかもしれない。RFC 2097は、その欠落を観測可能にした。

1997年1月刊行のPPP NetBIOS Frames Control Protocolは、NBFCP制御に0x803f、NBFデータグラムに0x003fを割り当てた。対象トポロジーは狭い。エンドシステムは相手システム、または相手が接続するLANへ到達できる。しかし、NetBIOS名の制約と名前防御の仕組みから、二つのLANを結ぶ用途は明示的に除外された。

回線を開くことと名前を受け入れることは別だった

PPPは仕事を段階に分けた。LCPはデータリンクを確立・設定・試験し、必要なら認証や品質判定が続く。NBFCPはNetwork-Layer Protocolフェーズ以前に交換してはならず、早すぎるパケットは黙って破棄される。NBFデータグラムを送れるのはNBFCPがOpenedになった後だけである。

それでもエンドシステムにはName-Projectionの交渉が必須だった。要求側は、相手に追加してほしい16オクテットのNetBIOS名を並べ、各項目を一意名かグループ名として示す。Lengthが1オクテットなので、一つのオプションに入るのは最大14名であり、それを超える集合には複数オプションが必要だった。

これは「NetBIOS対応」という能力ラベルではない。端末はサービスや役割ごとに複数の名前を必要とし得る。相手はそれぞれを自分の側のネットワークへ載せられるか試さなければならなかった。

部分的な受け入れは一覧のまま返された

受信側がすべての名前を追加できない場合、要求された完全な一覧をConfigure-Nakで返さなければならない。追加に成功した名前はAdded=0、失敗した名前は非ゼロの結果を持つ。ローカル名テーブルの重複、テーブル満杯、遠隔NetBIOSで使用中、競合検出、別環境による定義、システム資源枯渇などが区別された。

一覧は提案であると同時に受領記録だった。同時に要求した二つの名前が別々の結果を得る。要求側は成功した名前を再提出することが推奨されたが、全体が必要ならNBFCPを終了できた。部分成功がアプリケーションの要件まで決めるわけではない。

時間も証拠に含まれる。NetBIOS名の追加には通常約3秒かかり、PPPの既定再始動タイマーも3秒になり得た。RFC 2097は名前設定中に10秒を推奨した。早すぎる再送は、遠隔端末の不在ではなく制御ループの性急さを示すかもしれない。

したがってAdded=0から言えるのは、この交換で、この相手が、この要求名を追加できたと報告したことまでである。他のセグメント、名前サーバー、ブリッジの一貫した見解は証明しない。RFC 1001も、障害によって名前情報が不整合になり得ることを認めている。

相手の自己申告クラスは本人確認ではなかった

Peer-Informationは実装クラス、メジャー／マイナーバージョン、任意の相手名を伝えた。初期クラスはPPP NetBIOSゲートウェイ、ローカルアクセス専用サーバー、NBFブリッジ、エンドシステムを区別した。

これは運用上重要だった。ブリッジと、他のサーバーへパケットを通さないローカル専用サーバーでは、得られる到達面が違う。しかしオプションは必須ではなく推奨にとどまり、値も相手自身が送る。RFC 2097には、そのクラスや名前を検証済みの機械、組織、運用者へ結びつける認証機構がない。

マルチキャスト方針は到達可能なサービスを見えなくできた

NetBIOSアプリケーションには、マルチキャストが必要なものと不要なものがあった。Multicast-Filteringは最大転送周期と優先度ビットを交渉した。

周期ゼロはすべてのマルチキャストを転送する意味だった。通常値は最大60秒で、その間隔より頻繁には送らない。0xFFFFはRequestとNakで、値を相手に求める場合と利用可能な値がない場合を表した。優先度はマルチキャストと宛先指定パケットのどちらを先にするか決めた。

帯域方針がアプリケーションの見え方を左右する。リンクが開き、名前が投影され、宛先指定パケットが通っても、頻繁なマルチキャストに依存するアプリケーションは壊れたように見える。周期への合意は相手の扱い方を示すだけで、各パケットの到着を保証しない。

12オクテットが受け入れ可能な包の形を変えた

NBFには802.3 Ethernet、802.5 Token Ring、DIX Ethernet、FDDIという複数のMACヘッダー実装があった。PPP実装によってはブリッジのために完全なメディアヘッダーを要し、別の実装はIEEEアドレスだけを要し、ゲートウェイならMAC情報を不要とすることもあった。

IEEE-MAC-Address-Requiredはこの依存をブール値にした。既定ではMACヘッダーなし。交渉が成功すると、各NBFデータグラムは宛先・送信元の12オクテットIEEE MACヘッダーを持つ。これはLCPによるMRU交渉後に決まるため、受信側はMRUより12オクテット大きいNBFパケットも受け入れなければならなかった。

下位層のサイズ値だけでは包契約を言い尽くせない。ヘッダー観測が証明するのは表現形式であって、ブリッジによる転送や名前付き宛先での受信ではない。

Openedは狭い許可であって結果証明書ではない

四つのオプションは、監視画面が一つの緑表示にまとめがちな事実を分離した。どの名前が受け入れられたか、相手は何者だと申告したか、マルチキャストをどう扱うか、どのフレーム形が必要か。Openedは、その条件のもとでこの点対点回線にNBFを送る許可だった。

安全性の上乗せはない。Security Considerationsは安全性を論じないと明記した。NBFCPは人や機械を認証せず、名前を認可せず、暗号化や完全性を提供しない。LAN間用途を除外したこと自体が、局所投影と一般的な経路制御を区別している。

IANAは現在も二つのプロトコル値、四つのオプション、名前の結果コード、相手クラスを掲載する。それは番号の継続性であり、現用数、製品適合、相互接続の成功ではない。登録errataがないことも、実装の測定ではない。

RFC 1088との違いは明確である。RFC 1088はIPv4アドレスからIP-over-NetBIOS用の名前を機械的に導出した。RFC 2097は名前を作らず、相手が選んだ名前集合を遠隔の受け入れ点へ運び、項目ごとの結果を返した。

Lu Hengが後に示したMinimum Initial SpecificationとRunning-Code Primacyの枠組みから見れば、NBFCPは端点の相互運用に必要な約束だけを共有層へ置いた例に見える。これは編集上の比較であって、RFC著者の意図を示す証拠ではない。歴史的事実は単純だ。名前、相手役割、マルチキャスト、フレーム形に別々の受領記録ができた時、リンクアップはアクセスの同義語ではなくなった。

出典