要約

  • DRAP は、端末ごとに DLSw ピアを置く構成を、多数の軽量クライアントと一台のサーバー、一つの中央向け DLSw 接続へ置き換えた。
  • サーバーは MAC アドレスの割り当てと保持、到達性応答、能力交換、セッション識別、TCP 休止中の回線維持を担った。
  • これらは運用状態の証拠であって、人物の身元、認可、真正な出所、末端までの配送を証明しない。RFC 2106 は認証を規定せず、標準ではなく Informational だった。

端末数に比例する接続を止める

RFC 2106 の出発点は単純だった。遠隔端末がそれぞれ完全な DLSw を実装すれば、中央拠点へ向かう TCP セッションも端末数に比例する。スイッチ間で使う仕組みを、個々のワークステーションまで持ち込む設計になっていた。

DRAP は役割を組み替えた。端末は近くの DRAP サーバーのクライアントになり、サーバーだけが中央ルーターとの DLSw ピア関係を維持する。多数の端末を一つのバックボーン関係に畳み込める一方、端末が持っていた状態はサーバーに移る。消えたのは複雑さではなく、見える接続の本数だった。

既存記事との違いもここにある。RFC 1434 は二本のローカル LLC リンクと共有トランスポート、RFC 2024 は DLSw のディレクトリや回線を示す MIB、RFC 2043 は PPP 上の二つの SNA 許可、RFC 2097 は NetBIOS 名の個別受け入れを扱った。RFC 2106 は、境界サーバーが遠隔端末の代理として記憶し、答え、回線を保つ仕組みである。

仮想 MAC が示す範囲

PPP 接続の端末には IP アドレスがあっても LAN の MAC アドレスがないことがある。DRAP サーバーは仮想 MAC を割り当てられた。クライアントがゼロでない MAC を提示した場合、サーバーは重複を確認して記憶する。サーバーから始めるセッションのため、クライアントは MAC と IP を事前登録することもできた。

この割り当ては経路を成立させる。しかし、人間の身元を確認するものではない。利用者がそのアプリケーションを使う権限を持つか、登録情報が真正な発信元から来たかも示さない。キャッシュに入ったのは運用上の主張であり、身元証明ではなかった。

複数サーバーが設定された場合、クライアントは要求を送り、最初に応答したサーバーを選べた。最速の応答はその時点の生存性と遅延を示す。どの管理主体を信頼すべきかという問いには答えない。

状態遷移には固有の意味がある

CAN_U_REACH と I_CAN_REACH は、サーバーが対象への到達性をどう判断したかを表す。START_DL と DL_STARTED はリンク局を作る要求と結果である。送信側と受信側のセッション ID は回線を区別し、能力交換は MAC、NetBIOS 対応、SAP リスト、新しい TCP 接続を待ち受けられるかといった条件を整える。

肯定応答が示すのは、サーバーが到達可能だと回答した事実までである。リンク開始応答が示すのは、そのサーバー内の遷移が成功したことまでだ。アプリケーションへの配送、利用の認可、メッセージ外の出所まで一つの応答に背負わせることはできない。

RFC 2106 はクライアントとサーバーの組ごとに一つの双方向 TCP 接続を使い、ポート 1973 を指定した。さらに TCP だけを休止し、データリンク回線を残すことができた。新しい利用者データが出れば再接続し、能力交換を繰り返さずに再開する。任意の keepalive は応答性を確かめ、三回失敗すれば TCP と回線を閉じることが推奨された。

したがって「接続中」は一枚の状態ではない。ソケットがなくても論理回線は残り得る。keepalive に答えても業務トランザクションが末端へ届いたとは限らない。この層の違いを保つことが、運用証拠を正しく読む条件になる。

Informational 文書という位置付け

RFC 2106 は 1997 年 2 月に Informational として公開され、インターネット標準を定めるものではないと明記した。認証機構も Security Considerations 節もない。ここから言えるのは限定的だ。この文書は遠隔アクセスと状態遷移を記述したのであり、身元・認可の設計書ではなかった。

同じ月に RFC 2114 が RFC 2106 を置き換え、名称を DCAP とし、発見方法を追加した。中心的なクライアント／サーバー構造は残った。RFC 番号、登録ポート、動く実装は運用可能性を高めるが、それぞれ単独では永続的な標準合意を示さない。

情報源